Date: Wed, 6 Aug 2008 17:04:53 +0200 From: "Attilio Rao" <attilio@freebsd.org> To: "John Baldwin" <jhb@freebsd.org> Cc: cvs-src@freebsd.org, src-committers@freebsd.org, cvs-all@freebsd.org Subject: Re: 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: <3bbf2fe10808060804k5b843b5bma8d71d524497e8d8@mail.gmail.com> In-Reply-To: <200808052003.m75K3faN048818@repoman.freebsd.org> References: <200808052003.m75K3faN048818@repoman.freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
2008/8/5, John Baldwin <jhb@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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3bbf2fe10808060804k5b843b5bma8d71d524497e8d8>