wakeup_flags patch.

[John Baldwin]

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