On 10/29/24 1:14 PM, Vineet Gupta wrote:
On 10/29/24 11:51, Wilco Dijkstra wrote:
Hi Vineet,
I agree the NARROW/WIDE stuff is obfuscating things in technicalities.
Is there evidence this change would make things significantly worse for
some targets?
Honestly I don't think this needs to be behind any toggle or made optional at
all. The old algorithm was overly eager in spilling. But per last
discussion with Richard [1] at least back in 2012 for some in-order arm32 core
this was better. And also that's where the wide vs. narrow discussions
came up and that it really mattered, as far as I understood.
I'd agree across the board. In an ideal world we'd make
TARGET_SCHED_PRESSURE_SPILL_AGGRESSIVE default to false since I suspect
that's going to work best most of the time. But the safer thing to do
is make it true, preserving current behavior and let uarchs opt-in to
the new behavior.
There are already too many features in the scheduler - it would be better
to reduce the many variants and focus on doing really well on modern cores.
A purist might argue it is not really new algorithm, just a little tweak to
model algo. But I agree there's a zoo of sched toggles out there so this
might be ok. Anyhow I'm fine either way, whatever is more palatable for the
community / maintainers. @Jeff what say you.
You're kind of making Wilco's point ;-)
And while we are at it - I'd prefer the new behavior to be default for all
targets unless they explicitly opt out (and it would be insightful
understanding those not made up cases). But given how late we are in the
release cycle, I think it would be kosher to keep the old behavior for now
and maybe after gcc-15 is released we can flip the switch and deal with any
potential fallout.
I can make an argument for either default.
The safest thing to do is keep behavior as-is and opt-in to the new
behavior. I don't think asking you to verify this doesn't regress the
various aarch64 cores, s390 and ppc is reasonable. Hell, even just
verifying across risc-v cores would be nontrivial.
Jeff
