Date: Wed, 20 Oct 2004 01:36:06 -0400 From: Brian Fundakowski Feldman <green@freebsd.org> To: Julian Elischer <julian@elischer.org> Cc: FreeBSD Current <freebsd-current@freebsd.org> Subject: Re: wakeup/sleep handoff. Message-ID: <20041020053606.GG1072@green.homeunix.org> In-Reply-To: <41759681.1060700@elischer.org> References: <41759681.1060700@elischer.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, Oct 19, 2004 at 03:34:41PM -0700, 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.) This is essentially what Dillon's been espousing other than the possibility of running the operation in-line when feasible. -- Brian Fundakowski Feldman \'[ FreeBSD ]''''''''''\ <> green@FreeBSD.org \ The Power to Serve! \ Opinions expressed are my own. \,,,,,,,,,,,,,,,,,,,,,,\
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20041020053606.GG1072>