From owner-cvs-src@FreeBSD.ORG Wed Aug 6 15:04:55 2008 Return-Path: Delivered-To: cvs-src@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3345C1065672 for ; Wed, 6 Aug 2008 15:04:55 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.153]) by mx1.freebsd.org (Postfix) with ESMTP id B11048FC08 for ; Wed, 6 Aug 2008 15:04:54 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: by fg-out-1718.google.com with SMTP id l26so33428fgb.35 for ; Wed, 06 Aug 2008 08:04:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:sender :to:subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references :x-google-sender-auth; bh=+Yp4WxG+w0WnFLpk1dEwwoC0cAgFbYg9r6hrLk3wFJg=; b=to1maWb7qCVuhPVst3OBpDeq896yWyRc3LQzJZkDQzibDAHJ37m6+vc7j270YWDmWP 69t39FiEoETIGhn5vWKls5nZxAPCKDNMYopj70tR1NS5pHSRpqEHUVtFbo3/uFYTpfd6 8LSka19dVoP3ofGUrmySMPcLKDKVdkl6wKvYQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references:x-google-sender-auth; b=vhqQd6vp3H5bbDhCS4irqlzumJjshFi9yuumFqVViAVEjijy+pvQ974+613YfdSCl+ Q+nLQrNeL2HwNuPToQ9JapZwg/fuAb1LFhxJVmxo94ZtvCWZzsLQlHUlsZ/s/yoOr9Hd jfwmWYjHoO8frBJZrcqWaW8GfwEpV/iEnQQWg= Received: by 10.86.89.1 with SMTP id m1mr857313fgb.68.1218035093621; Wed, 06 Aug 2008 08:04:53 -0700 (PDT) Received: by 10.86.78.14 with HTTP; Wed, 6 Aug 2008 08:04:53 -0700 (PDT) Message-ID: <3bbf2fe10808060804k5b843b5bma8d71d524497e8d8@mail.gmail.com> Date: Wed, 6 Aug 2008 17:04:53 +0200 From: "Attilio Rao" Sender: asmrookie@gmail.com To: "John Baldwin" In-Reply-To: <200808052003.m75K3faN048818@repoman.freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <200808052003.m75K3faN048818@repoman.freebsd.org> X-Google-Sender-Auth: 188fd5fb8287fd26 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 X-BeenThere: cvs-src@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: CVS commit messages for the src tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Aug 2008 15:04:55 -0000 2008/8/5, John Baldwin : > 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