From owner-freebsd-current@FreeBSD.ORG Tue Nov 2 15:12:44 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 94B0916A4CE for ; Tue, 2 Nov 2004 15:12:44 +0000 (GMT) Received: from duchess.speedfactory.net (duchess.speedfactory.net [66.23.201.84]) by mx1.FreeBSD.org (Postfix) with SMTP id 218F643D54 for ; Tue, 2 Nov 2004 15:12:44 +0000 (GMT) (envelope-from ups@tree.com) Received: (qmail 29609 invoked by uid 89); 2 Nov 2004 15:12:42 -0000 Received: from duchess.speedfactory.net (66.23.201.84) by duchess.speedfactory.net with SMTP; 2 Nov 2004 15:12:42 -0000 Received: (qmail 27738 invoked by uid 89); 2 Nov 2004 15:12:05 -0000 Received: from unknown (HELO palm.tree.com) (66.23.216.49) by duchess.speedfactory.net with SMTP; 2 Nov 2004 15:12:05 -0000 Received: from [127.0.0.1] (localhost.tree.com [127.0.0.1]) by palm.tree.com (8.12.10/8.12.10) with ESMTP id iA2FC55R089081; Tue, 2 Nov 2004 10:12:05 -0500 (EST) (envelope-from ups@tree.com) From: Stephan Uphoff To: Julian Elischer In-Reply-To: <4176C94E.3000700@elischer.org> References: <41759681.1060700@elischer.org> <4176C94E.3000700@elischer.org> Content-Type: text/plain Message-Id: <1099408325.88989.6.camel@palm.tree.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Tue, 02 Nov 2004 10:12:05 -0500 Content-Transfer-Encoding: 7bit cc: FreeBSD Current 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: Tue, 02 Nov 2004 15:12:44 -0000 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? Stephan