From owner-freebsd-current@FreeBSD.ORG Wed Oct 20 20:23:43 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 1A38016A4CE for ; Wed, 20 Oct 2004 20:23:42 +0000 (GMT) Received: from mail.vicor-nb.com (bigwoop.vicor-nb.com [208.206.78.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 99E2543D5A for ; Wed, 20 Oct 2004 20:23:42 +0000 (GMT) (envelope-from julian@elischer.org) Received: from elischer.org (julian.vicor-nb.com [208.206.78.97]) by mail.vicor-nb.com (Postfix) with ESMTP id 55D567A41E; Wed, 20 Oct 2004 13:23:42 -0700 (PDT) Message-ID: <4176C94E.3000700@elischer.org> Date: Wed, 20 Oct 2004 13:23:42 -0700 From: Julian Elischer User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.3.1) Gecko/20030516 X-Accept-Language: en, hu MIME-Version: 1.0 To: Stephan Uphoff References: <41759681.1060700@elischer.org> <1098237638.15834.105.camel@palm.tree.com> In-Reply-To: <1098237638.15834.105.camel@palm.tree.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed 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: Wed, 20 Oct 2004 20:23:43 -0000 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. > > Stephan > >