Date: Thu, 28 Jun 2007 23:28:18 +0200 From: "Attilio Rao" <attilio@freebsd.org> To: "Jeff Roberson" <jroberson@chesapeake.net> Cc: freebsd-arch@freebsd.org Subject: Re: Add wakeup_with() before 7.0? Message-ID: <3bbf2fe10706281428t3543c396q5cb5bb61685a987f@mail.gmail.com> In-Reply-To: <20070628135758.U552@10.0.0.1> References: <20070628123314.W552@10.0.0.1> <200706281653.37930.jhb@freebsd.org> <20070628135758.U552@10.0.0.1>
next in thread | previous in thread | raw e-mail | index | archive | help
2007/6/28, Jeff Roberson <jroberson@chesapeake.net>: > On Thu, 28 Jun 2007, John Baldwin wrote: > > > On Thursday 28 June 2007 03:41:15 pm Jeff Roberson wrote: > >> I propose to add a new api for wakeup before 7.0. This new api would > >> accept a wait channel and a flags argument. here's the relevant part of > >> the diff: > >> > >> +void wakeup_with(void *chan, int flags) __nonnull(1); > >> +#define WAKEUP_ONE 0x00001 /* Only wakeup on thread. > >> */ > >> +#define WAKEUP_ALL 0x00002 /* Wake-up all waiters. */ > >> +#define WAKEUP_LOCAL 0x00004 /* Wake-up on the local > >> cpu. */ > >> +#define WAKEUP_TAIL 0x00008 /* Wake-up the newest > >> waiter. */ > >> > >> This allows wakeup callers to hint the scheduler about various > >> information. WAKEUP_LOCAL would allow us to prefer affinity for the > >> waking cpu. I have patches to use this in pipe code and socket buffer > >> code that improve performance in some workloads. WAKEUP_TAIL could be > >> used for accept() which I have heard can significantly improve webserver > >> performance. > >> > >> To implement this change sched_wakeup() and setrunnable() need the flags > >> plummed all the way through. I would like feedback on whether people > >> think the api breakage should go in now to enable these optimizations for > >> 7.0, potentially without committing users of these flags right away. > >> Alternatively we could break the api later or just skip it until 8.0. > > > > We have something like WAKEUP_TAIL (but different, it also prefers non-swapped > > out processes in addition to taking the most recently suspended thread) at > > work for accept() and it just modifies the sleepq code's choice in > > sleepq_signal() of which thread to pick, it doesn't touch any of the > > scheduler stuff at all. OTOH, I think the scheduler ABIs are ok to change > > during 7.x as they aren't exposed to any KLD's (no well-behaving ones anyway) > > as drivers, etc. should all be using higher-level APIs like cv_*() or > > *sleep(). > > In my implementation the WAKEUP_TAIL call just changes the sleepq as well. > It doesn't go down to the scheduler. I agree that well behaving drivers > should not use setrunnable() or sched_wakeup(). Maybe that is ok to > break later. Any other opinions? 1) I would like to call the function wakeup_flags() as wakeup_with() is not approprate IMHO 2) I would commit just for 8.0 since currently there is no real consumer of it. For 8.0 we can have time to rework the accept code in order to use it 3) Is the code of wakeup_with() alredy available? Thanks, Attilio -- Peace can only be achieved by understanding - A. Einstein
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3bbf2fe10706281428t3543c396q5cb5bb61685a987f>