cvs commit: src/sys/kern kern_condvar.c kern_lock.c kern_sig.c kern_sx.c kern_synch.c kern_thread.c subr_sleepqueue.c src/sys/sys proc.h sleepqueue.h src/sys/vm vm_glue.c

[Attilio Rao]

2008/8/5, John Baldwin <jhb at freebsd.org>:
> jhb         2008-08-05 20:02:31 UTC
>
>  FreeBSD src repository
>
>  Modified files:
>    sys/kern             kern_condvar.c kern_lock.c kern_sig.c
>                         kern_sx.c kern_synch.c kern_thread.c
>                         subr_sleepqueue.c
>    sys/sys              proc.h sleepqueue.h
>    sys/vm               vm_glue.c
>  Log:
>  SVN rev 181334 on 2008-08-05 20:02:31Z by jhb
>
>  If a thread that is swapped out is made runnable, then the setrunnable()
>  routine wakes up proc0 so that proc0 can swap the thread back in.
>  Historically, this has been done by waking up proc0 directly from
>  setrunnable() itself via a wakeup().  When waking up a sleeping thread
>  that was swapped out (the usual case when waking proc0 since only sleeping
>  threads are eligible to be swapped out), this resulted in a bit of
>  recursion (e.g. wakeup() -> setrunnable() -> wakeup()).
>
>  With sleep queues having separate locks in 6.x and later, this caused a
>  spin lock LOR (sleepq lock -> sched_lock/thread lock -> sleepq lock).
>  An attempt was made to fix this in 7.0 by making the proc0 wakeup use
>  the ithread mechanism for doing the wakeup.  However, this required
>  grabbing proc0's thread lock to perform the wakeup.  If proc0 was asleep
>  elsewhere in the kernel (e.g. waiting for disk I/O), then this degenerated
>  into the same LOR since the thread lock would be some other sleepq lock.
>
>  Fix this by deferring the wakeup of the swapper until after the sleepq
>  lock held by the upper layer has been locked.  The setrunnable() routine
>  now returns a boolean value to indicate whether or not proc0 needs to be
>  woken up.  The end result is that consumers of the sleepq API such as
>  *sleep/wakeup, condition variables, sx locks, and lockmgr, have to wakeup
>  proc0 if they get a non-zero return value from sleepq_abort(),
>  sleepq_broadcast(), or sleepq_signal().

Could you please update sleepqueue(9) manpages reflecting prototipes
changes for sleepq_* functions?

Thanks,
Attilio


-- 
Peace can only be achieved by understanding - A. Einstein