Re: new IRQ scalability changes in 2.3.48

From: Ingo Molnar (mingo@chiara.csoma.elte.hu)
Date: Mon Mar 13 2000 - 09:57:44 EST


> >imagine. It's these two additional (nonlocked) instructions on x86:
> >
> > decl %0
> > jz 1f
> >.section offline.preempt
> > call do_reschedule

sorry you are right it's buggy - it's actually 3 instructions:

        decl current->spinlock_depth
        subl current->need_resched
        js 1f
.section offline.preempt
        call do_reschedule

this way we jump away only if spinlock_depth is 0 and need_resched is 1.
(thats the only normal way how the subl can get negative, assuming that
spinlock_depth is not more than 2 billion :-)

and 1 instruction total in the spin_lock path. (additionally there might
be 1-2 instructions if 'current' is not yet available in that function)
Still they are fast instructions all.

in fact there is a (slightly dangerous) optimization that reduces this to
2 instructions again:

        decl current->spinlock_depth_need_resched
        js 1f
.section offline.preempt
        call do_reschedule

spinlock_depth_need_resched is decremented by 1 if need_resched is changed
from 0 to 1, and is incremented by 1 if need_resched goes from 1 to 0.
schedule() in this case has to check:

        if (current->spinlock_depth_need_resched + current->need_resched)
                BUG();

but all the fast path (setting need_resched is much more rare than using a
spinlock) is still only 2 instructions again.

        Ingo

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/



This archive was generated by hypermail 2b29 : Wed Mar 15 2000 - 21:00:24 EST