Date: Mon, 2 Jul 2007 15:54:29 -0400 From: John Baldwin <jhb@freebsd.org> To: Jeff Roberson <jroberson@chesapeake.net> Cc: freebsd-arch@freebsd.org Subject: Re: wakeup_flags patch. Message-ID: <200707021554.29687.jhb@freebsd.org> In-Reply-To: <20070702120445.X552@10.0.0.1> References: <20070701160540.Y552@10.0.0.1> <200707021454.39923.jhb@freebsd.org> <20070702120445.X552@10.0.0.1>
next in thread | previous in thread | raw e-mail | index | archive | help
On Monday 02 July 2007 03:06:03 pm Jeff Roberson wrote: > On Mon, 2 Jul 2007, John Baldwin wrote: > > > On Sunday 01 July 2007 07:08:35 pm Jeff Roberson wrote: > >> http://people.freebsd.org/~jeff/wakeupflags.diff > >> > >> It didn't workout very cleanly since the flags have to go through three > >> layers. I could define wakeup and sleepq flags to be the same and skip a > >> bunch of conditionals. However, we'd then have to know which flags were > >> free to use in each case. Are there any further opinions on the style? > >> > >> This patch does not include an implementation for WAKEUP_LOCAL. I'm still > >> working on that in SCHED_SMP. Ironically, it does include an > >> implementation for WAKEUP_TAIL, however, I don't have any users of that. > >> :-) > > > > You can find the pre-threadlock patch for 7.x of what Y! uses for accept() at > > www.freebsd.org/~jhb/patches/justone.patch > > > > It has two features your WAKEUP_TAIL doesn't have (one of which I mentioned > > earlier): 1) it doesn't wakeup threads from swapped out processes (you aren't > > getting a thread that is "hot" in the cache if you have to go page it back in > > from disk), and 2) it returns a success/fail to the caller so that it can > > fallback to its traditional behavior if we couldn't find a "hot" thread to > > resume. > > Shouldn't we simply choose a non-hot thread in this case? In your > environment is it common to have a lot of swapped out proceses? It would > be expensive to lock and unlock each thread to check if it's swapped. > Perhaps we can simply do it in a racey way. accept() does a wakeup() actually IIRC. We do have boxes with lots of swapped out processes (though often that can be a sign of an overloaded box). I was mostly submitting this as a known-working patch that has been used under real-world load in at least 4.x through 6.x so that it can be drawn from. -- John Baldwin
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200707021554.29687.jhb>