[lkml]   [2001]   [Jan]   [13]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectLatency: allowing resheduling while holding spin_locks

A rethinking of the rescheduling strategy...

I have come to this conclusion.

A spinlock prevents other processes to enter that specific region.
But interrupts are allowed they might delay
execution of a spin locked
reqion for a undefined (small but anyway) time.

Code with critical maximum times should use spin_lock_irq !

=> spin_locks are not about disallowing reschedules.

Prior to the introduction of spin locks it did not make sense to
allow reschedules in kernel since the big kernel lock was so big...
Any code that wanted do any non pure computation task would
hit it very quickly.

Now with spin locks the situation is quite different...

[First assume UP kernel for simplicity]

Suppose you have two processes one that normal (P) and one high priority

P runs user code, makes a system call, enters a spin lock region.


The interrupt service routine wakes up RTP, which marks P as need_reschedule,
and returns, on return from interrupt it detects that P needs_reschedule -
do it even if it is executing in kernel and holding a spin_lock.

RTP starts, and if it does not hit the same spin_lock there is nothing
special happening until it goes to sleep again. But suppose it does!

RTP tries to get the spin_lock but fails, since it is the currently highest
prio process and P is running it wants to reschedule to P to get its own
stuff done.

P runs the final part of its spin_locked region, upon spin_unlock it needs to
get RTP running.

Something like this:

while (test_and_set(lock->lock)) {
schedule_spinlock(); /* kind of yield, giving low goodness, sticky */


/* note: someone with higher prio than me,
might steal the lock from even higher prio waiters here */

if (lock->queue)

/* note: owner can not run here, it has lower prio */

addqueue(lock->queue, current);

p->policy |= SCHED_SPINLOCK;

int need_resched = 0;

int my_goodness = goodness(current);

forall p in lock->queue
p->policy &= ~SCHED_SPINLOCK;
if (goodness(p) > my_goodness)
need_resched = 1;

if (need_resched)

A final note on spin_lock_irq, since they prevent IRQs there will be no
requests to wakeup any process during their locked region => no problems.

Home page:
no currently
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
Please read the FAQ at

 \ /
  Last update: 2005-03-22 13:28    [W:0.052 / U:0.596 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site