Preempt of BKL and with tickless systems

Preempt of BKL and with tickless systems

[Bill Davidsen]

I think I have a reasonable grip on the voluntary and full preempt 
models, can anyone give me any wisdom on the preempt of the BKL? I know 
what it does, the question is where it might make a difference under 
normal loads. Define normal as servers and desktops.

I've been running some sched tests, and it seems to make little 
difference how that's set. Before I run a bunch of extra tests, I 
thought I'd ask.


New topic: I have found preempt, both voluntary and forced, seems to 
help more with response as the HZ gets smaller. How does that play with 
tickless operation, or are you-all waiting for me to run my numbers with 
all values of HZ and not, and tell the world what I found? ;-)

-- 
Bill Davidsen <davidsen@tmr.com>
   "We have more to fear from the bungling of the incompetent than from
the machinations of the wicked."  - from Slashdot

Re: Preempt of BKL and with tickless systems

[Lee Revell]

On 5/8/07, Bill Davidsen <davidsen@tmr.com> wrote:
> I think I have a reasonable grip on the voluntary and full preempt
> models, can anyone give me any wisdom on the preempt of the BKL? I know
> what it does, the question is where it might make a difference under
> normal loads. Define normal as servers and desktops.

This was introduced by Ingo to solve a real problem that I found,
where some codepath would hold the BKL for long enough to introduce
excessive scheduling latencies - search list archive for details.  But
I don't remember the code path (scrolling the FB console?  VT
switching? reiser3?  misc. ioctl()s?).  Basically, taking the BKL
disabled preemption which caused long latencies.

It's certainly possible that whatever issue led to this was solved in
another way since.

Lee

Re: Preempt of BKL and with tickless systems

[Bill Davidsen]

Lee Revell wrote:
> On 5/8/07, Bill Davidsen <davidsen@tmr.com> wrote:
>> I think I have a reasonable grip on the voluntary and full preempt
>> models, can anyone give me any wisdom on the preempt of the BKL? I know
>> what it does, the question is where it might make a difference under
>> normal loads. Define normal as servers and desktops.
> 
> This was introduced by Ingo to solve a real problem that I found,
> where some codepath would hold the BKL for long enough to introduce
> excessive scheduling latencies - search list archive for details.  But
> I don't remember the code path (scrolling the FB console?  VT
> switching? reiser3?  misc. ioctl()s?).  Basically, taking the BKL
> disabled preemption which caused long latencies.
> 
> It's certainly possible that whatever issue led to this was solved in
> another way since.
> 
Anything is possible. I feel that using voluntary + bkl is probably good 
for most servers, forced preempt for desktop, although it really doesn't 
seem to do much beyond voluntary.

Thanks for the clarification.

-- 
Bill Davidsen <davidsen@tmr.com>
   "We have more to fear from the bungling of the incompetent than from
the machinations of the wicked."  - from Slashdot

Re: Preempt of BKL and with tickless systems

[Ingo Molnar]

* Bill Davidsen <davidsen@tmr.com> wrote:

> > This was introduced by Ingo to solve a real problem that I found, 
> > where some codepath would hold the BKL for long enough to introduce 
> > excessive scheduling latencies - search list archive for details.  
> > But I don't remember the code path (scrolling the FB console?  VT 
> > switching? reiser3?  misc. ioctl()s?).  Basically, taking the BKL 
> > disabled preemption which caused long latencies.
> >
> > It's certainly possible that whatever issue led to this was solved 
> > in another way since.
>
> Anything is possible. I feel that using voluntary + bkl is probably 
> good for most servers, forced preempt for desktop, although it really 
> doesn't seem to do much beyond voluntary.

yeah - we default to PREEMPT_BKL on plain SMP kernels, so it's enabled 
on the majority of enterprise distros and it's working pretty well in 
practice.

even today there are a couple of bad BKL latencies still: Lee mentioned 
ioctls and reiser3 - neither has been fixed since i wrote 
CONFIG_PREEMPT_BKL two years ago. Turning the BKL into a semaphore does 
not reduce BKL latencies itself, but it makes all _other_ workloads 
schedule sanely and without delay. With PREEMPT_BKL disabled (which 
turns on the big kernel spinlock again) any big BKL delay is immediately 
felt by other tasks too, because we waste that CPU time spinning on the 
big kernel spinlock.

	Ingo