Messages in this thread | | | Date | Wed, 7 Oct 2009 11:02:57 -0400 | From | Mathieu Desnoyers <> | Subject | Re: [this_cpu_xx V5 19/19] SLUB: Experimental new fastpath w/o interrupt disable |
| |
* Christoph Lameter (cl@linux-foundation.org) wrote: > On Wed, 7 Oct 2009, Mathieu Desnoyers wrote: > > > Yes, I understood this is what he was doing, but I wonder about the > > impact on the scheduler. If we have: > > > > * Jiffy 1 -- timer interrupt > > > > * preempt disable > > * Jiffy 2 -- timer interrupt > > -> here, the scheduler is disabled, so the timer interrupt is skipped. > > The scheduler depends on preempt_check_resched() at preempt_enable() > > to execute in a bounded amount of time. > > preempt disable does not disable interrupts. The timer interrupt will > occur. The scheduler may not reschedule another job on this processor > when the timer interrupt calls the scheduler_tick. It > may not do load balancing.
Yes. All you say here is true. I'm concerned about the _impact_ of this along with the preempt/irqoff dance you propose. Trimming the following key points from my execution scenario indeed skips the problem altogether.
Usually, when preemption is disabled, the scheduler restrain from executing. *Now the important point*: the criterion that bounds the maximum amount of time before the scheduler will re-check for pending preemption is when preempt_enable() will re-activate preemption.
But because you run preempt_enable with interrupts off, the scheduler check is not done. And it's not done when interrupts are re-activated neither.
Please go back to my complete execution scenario, you'll probably see the light. ;)
Thanks,
Mathieu
> > > Also, preempt_enable here should be replaced with > > preempt_enable_no_resched(). > > Used to have that in earlier incarnations but I saw a lot of these being > removed lately. > > >
-- Mathieu Desnoyers OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F BA06 3F25 A8FE 3BAE 9A68
| |