Re: [POC][RFC][PATCH] sched: Extended Scheduler Time Slice

[Ankur Arora]

Peter Zijlstra <peterz@xxxxxxxxxxxxx> writes:

> On Wed, Oct 25, 2023 at 05:42:19AM -0400, Steven Rostedt wrote:
>
>> So, bit 1 is for user space to tell the kernel "please extend me", and bit
>> two is for the kernel to tell user space "OK, I extended you, but call
>> sched_yield() when done".
>
> So what if it doesn't ? Can we kill it for not playing nice ?
>
> [ aside from it being bit 0 and bit 1 as you yourself point out, it is
>   also jarring you use a numeral for one and write out the other. ]
>
> That said, I properly hate all these things, extending a slice doesn't
> reliably work and we're always left with people demanding an ever longer
> extension.
>
> The *much* better heuristic is what the kernel uses, don't spin if the
> lock holder isn't running.

Something like vcpu_is_preempted()? That helps deal with preemption
once it has happened, but an ahead of time signal would be much more
efficient.

And, guest lock holder preemption was a big enough issue that we drop
down to test-and-set spinlocks in some cases.


Thanks

--
ankur