Re: would a mutex_wait be useful?

[Antti Kantee <pooka%cs.hut.fi@localhost>]

On Tue Nov 04 2008 at 20:24:20 +0000, Christos Zoulas wrote:
> In article <20081104200024.AAB3863B10C%mail.netbsd.org@localhost>,
> Mindaugas Rasiukevicius  <rmind%NetBSD.org@localhost> wrote:
> >Mindaugas Rasiukevicius <rmind%NetBSD.org@localhost> wrote:
> >> Matt Thomas <matt%3am-software.com@localhost> wrote:
> >> > > Where/when do you need interruptible mutex?
> >> > 
> >> > I was replacing code in arm32/mem.c with a home grown lock with  
> >> > mutex_enter.
> >> > Relatively easy to do except it no longer does PCATCH.
> >> 
> >> I agree with Antti that code asks for condvar(9), at least.
> >
> >Actually, taken a look at arm32/mem.c again, no need for condvar(9). If there
> >is a contention on mm_lock, hashed locks would help. Is it worth?
> >
> >You probably was intended to set the D_MPSAFE flag for mem_cdevsw. Note that
> >this wont be atomic then:
> >
> >if (zeropage == NULL) {
> >     zeropage = (void *)
> >         malloc(PAGE_SIZE, M_TEMP, M_WAITOK);
> >     memset(zeropage, 0, PAGE_SIZE);
> >}
> >
> 
> if (zeropage == NULL)
>       zeropage = malloc(PAGE_SIZE, M_TEMP, M_WAITOK|M_ZERO);
> 
> Not a good reason :-)

In which case you get a test-and-set race without a lock, which is
less good.
(and why doesn't that come from bss anyway?  optimization in case
nobody ever uses devzero?  problems with variable page size?)

But, I'm not really convinced ripping locks out of everything just for
the sheer fun of it is a good idea.  Sounds like optimizing for the
wrong case to me.  Is this path *measurably* that contended?