Date: Tue, 5 Aug 2008 20:02:31 +0000 (UTC) From: John Baldwin <jhb@FreeBSD.org> To: src-committers@FreeBSD.org, cvs-src@FreeBSD.org, cvs-all@FreeBSD.org Subject: 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 Message-ID: <200808052003.m75K3faN048818@repoman.freebsd.org>
next in thread | raw e-mail | index | archive | help
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().
Discussed with: jeff
Glanced at by: sam
Tested by: Jurgen Weber jurgen - ish com au
MFC after: 2 weeks
Revision Changes Path
1.64 +11 -2 src/sys/kern/kern_condvar.c
1.135 +16 -9 src/sys/kern/kern_lock.c
1.362 +10 -2 src/sys/kern/kern_sig.c
1.61 +17 -6 src/sys/kern/kern_sx.c
1.312 +17 -15 src/sys/kern/kern_synch.c
1.275 +11 -3 src/sys/kern/kern_thread.c
1.56 +49 -18 src/sys/kern/subr_sleepqueue.c
1.517 +1 -1 src/sys/sys/proc.h
1.15 +3 -3 src/sys/sys/sleepqueue.h
1.232 +14 -37 src/sys/vm/vm_glue.c
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200808052003.m75K3faN048818>