Messages in this thread | | | Date | Thu, 9 Mar 2023 16:29:04 +0100 | From | Peter Zijlstra <> | Subject | Re: [PATCH 10/10] sched/fair: Implement an EEVDF like policy |
| |
On Thu, Mar 09, 2023 at 01:44:13PM +0100, Peter Zijlstra wrote: > On Thu, Mar 09, 2023 at 10:06:33AM +0100, Peter Zijlstra wrote: > > Hi Mike! > > > > On Wed, Mar 08, 2023 at 02:36:01PM +0100, Mike Galbraith wrote: > > > On Wed, 2023-03-08 at 09:39 +0100, Mike Galbraith wrote: > > > > > > > > Curiosity got the best of me... > > > > > > Remember this little bugger, allegedly distilled from a real > > > application control thread starvation issue? > > > > Oooh, yeah, I should still have that somewhere. I'll try and remember > > what exactly was needed to make it behave properly. > > That thing wants both wakeup preemption and sleeper bonus. Specifically, > it needs the signal to insta-preempt the 'pointless' kill loop. > > What happens is that while positive lag, we get this, when negative lag > happens wakeup-preemption is not achieved and we get delayed by a full > tick. > > This gets us very little actual runtime. > > Let me see what do do about that...
So if I add TICK_NSEC based sleeper bonus (/2 for gentle), then starve works -- this is the absolutely minimal amount required. It sucks a bit it's HZ dependent, but alas.
Also, the whole sleeper bonus gets us back into needing to track the old vruntime and the overflow crap for super long sleeps and all that fugly :/ I was so hoping we could delete that code.
Oh well.
(also, did you know that removing the debug cruft helps with running numbers? ;-)
I think it adds a bit of variance to the numbers -- but I've not ran long enough to tell with certainty.
| |