From owner-freebsd-current@FreeBSD.ORG Fri Nov 5 00:40:04 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5DE5016A4CE for ; Fri, 5 Nov 2004 00:40:04 +0000 (GMT) Received: from mail3.speakeasy.net (mail3.speakeasy.net [216.254.0.203]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2F50843D45 for ; Fri, 5 Nov 2004 00:40:04 +0000 (GMT) (envelope-from jhb@FreeBSD.org) Received: (qmail 9646 invoked from network); 5 Nov 2004 00:40:03 -0000 Received: from dsl027-160-063.atl1.dsl.speakeasy.net (HELO server.baldwin.cx) ([216.27.160.63]) (envelope-sender ) encrypted SMTP for ; 5 Nov 2004 00:40:03 -0000 Received: from [10.50.41.235] (gw1.twc.weather.com [216.133.140.1]) (authenticated bits=0) by server.baldwin.cx (8.12.11/8.12.11) with ESMTP id iA50dt8o089851; Thu, 4 Nov 2004 19:39:56 -0500 (EST) (envelope-from jhb@FreeBSD.org) From: John Baldwin To: freebsd-current@FreeBSD.org Date: Thu, 4 Nov 2004 18:59:50 -0500 User-Agent: KMail/1.6.2 References: <41759681.1060700@elischer.org> <4176C94E.3000700@elischer.org> <1099408325.88989.6.camel@palm.tree.com> In-Reply-To: <1099408325.88989.6.camel@palm.tree.com> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200411041859.50511.jhb@FreeBSD.org> X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on server.baldwin.cx cc: Julian Elischer cc: Stephan Uphoff Subject: Re: wakeup/sleep handoff. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Nov 2004 00:40:04 -0000 On Tuesday 02 November 2004 10:12 am, Stephan Uphoff wrote: > On Wed, 2004-10-20 at 16:23, Julian Elischer wrote: > > Stephan Uphoff wrote: > > >On Tue, 2004-10-19 at 18:34, Julian Elischer wrote: > > >>Is there a need to be able to somehow implement a 'wakeup_one()' that > > >>as part of its semantic is that the woken thread will run immediatly, > > >>(as in preemprion), > > >>and the old thread will sleep? With preemption, the old thread is left > > >>in the run queue, > > >>and after the other thread has completed, it will > > >>run again and probably go away and sleep for some reason.. (or at least > > >>go do some work that isn't > > >>necessarily required..) > > >> > > >>Something like handover(wakeupchan, sleepchan, msleep_args...). > > >> sort of an atomic wakeup/msleep. > > >> > > >>This would be used in places where work used to be done by the same > > >>thread, but is now done > > >>by a server thread.. > > >> > > >>An example would be kicking off a geom thread, when in the past we > > >> would have gone all > > >>the way down to the hardware ourself. we want to get as close to acting > > >>like we are still > > >>going all the way done as we can (performance wise). We may get some > > >>efficiency by > > >>letting the sleep system, and scheduler know what we are trying to do. > > >>Possibly with some > > >>priority inherritance implications.. (if we have a high priority, we > > >>probably want to ensure that the > > >>worker thread is run with at least that priority.) > > > > > >Why not just give the geom thread a high priority? > > >This, full preemption and changing a few functions to guaranty that the > > >highest priority thread will always run should do what you want. > > >( And maybe always raising the priority of threads working in the > > >kernel) > > >Actually this is relatively high on my to do list and I should have some > > >patches to try out in a week or two. > > > > yessss but after the preemption (which is invisible to the caller of > > setrunqueue/wakeup) > > that thread continues on to do it's "check for completion/sleep".. > > > > it would be more efficient in my book to have an official way to hand > > over to a designated worker > > all in one hit.. You could then optimise such cases.. They are often in > > required fast-paths. > > OK - I finally got it. > > Maybe sections that temporarily disable preemption would do the trick. > Spinning on an adaptive mutex or blocking/sleeping should automatically > re-enable preemption. > > On a related topic: > I don't like the way condition variables and msleep wait threads will be > scheduled on a wakeup - just to block again on trying to acquire a > mutex. However I don't see any way to avoid this that does not involve a > lot of work. Any idea beside not protecting the wakeup by a mutex? wakeup() and now cv_signal() and cv_broadcast() do not require the lock to be held, so I think that is the best approach. -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve" = http://www.FreeBSD.org