Date: Mon, 2 Jul 2007 12:06:03 -0700 (PDT) From: Jeff Roberson <jroberson@chesapeake.net> To: John Baldwin <jhb@freebsd.org> Cc: arch@freebsd.org, freebsd-arch@freebsd.org Subject: Re: wakeup_flags patch. Message-ID: <20070702120445.X552@10.0.0.1> In-Reply-To: <200707021454.39923.jhb@freebsd.org> References: <20070701160540.Y552@10.0.0.1> <200707021454.39923.jhb@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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. Jeff > > -- > John Baldwin >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20070702120445.X552>