Getting rid of the static msleep priority boost

[Alfred Perlstein]

* John Baldwin <jhb at freebsd.org> [080319 12:28] wrote:
> On Wednesday 19 March 2008 01:23:44 pm Alfred Perlstein wrote:
> > * Jeff Roberson <jroberson at chesapeake.net> [080319 02:51] wrote:
> > > On Wed, 19 Mar 2008, David Xu wrote:
> > > 
> > > >Daniel Eischen wrote:
> > > >
> > > >>I'm not sure if any of the above remove the priority from the API,
> > > >>but it would be nice to get rid of msleep totally and replace it
> > > >>with an equivalent cv_wait().
> > > >>
> > > >
> > > >And create sleep queue in each cv to get rid of shared sleep queue
> > > >lock ?
> > > 
> > > Some spinlock is required to interlock with the scheduler lock via 
> > > thread_lock().  So I don't think you can get rid of that layer.  You also 
> > > wouldn't want to have the cost of a 'struct sleepqueue' everywhere you 
> > > want a msleep/condvar.
> > > 
> > > I personally don't see any real advantage to using condvar everywhere. 
> > > The only thing you really get is protection against spurious wakeups.
> > 
> > In theory can't you protect the waitq hung off of condvars with
> > the mutex/spinlock used for the condvar instead of a global 
> > (hashed) lock on the global waitq?
> 
> Right now we let people invoke cv_wakeup/signal w/o holding the lock.  I 
> actually took the thread queue out of condvar's back when doing the original 
> sleep queue stuff since it is cheaper space wise.  Instead of each possible 
> condvar having its own set of queue pointers you just have a set of queue 
> pointers for each thread in the system.  Similar to only have a turnstile per 
> thread rather than per lock.

Ok, thank you, need to think about it.

-- 
- Alfred Perlstein