Date: Tue, 23 Jan 2001 14:43:50 -0500 From: "Bosko Milekic" <bmilekic@dsuper.net> To: "John Baldwin" <jhb@FreeBSD.ORG>, "Alfred Perlstein" <bright@wintelcom.net> Cc: "Dag-Erling Smorgrav" <des@ofug.org>, <arch@FreeBSD.ORG>, "Bruce Evans" <bde@zeta.org.au> Subject: Re: Second zone allocator patch Message-ID: <B0000463571@www.marianopolis.edu>
next in thread | raw e-mail | index | archive | help
John Baldwin wrote:
[...]
> > There shouldn't be a problem with an interrupt blocking on a
> > mutex. However there could be a problem if an interrupt
> > stalls for too long because currently we only have a single
> > interrupt thread per software interrupt class, if that gets
> > stalled and happens to be the network thread we can't process
> > any more packets in order to possibly free up the reasources
> > needed.
> >
> > I think that, non-sleeping versions should continue to remain
> > available.
>
> Yes, but the zone allocator can just use normal mutexes and achieve this.
No
> need for spin mutexes. Also, to help with the problem of a software or
That's right. A "sleep" and a "waiting for lock" shouldn't be treated the
same way.
A cv sleep and {m,t}sleep() are "sleeps." A mtx_enter(&lock, MTX_DEF)
shouldn't be considered a "sleep." I think Alfred was pretty clear when he
said "non-sleeping versions should continue to remain available," given
this consideration.
> hardware interrupt handler blocking and stalling other interrups, Jake
and I
> have toyed with the notion of creating a new kthread to run the other
handlers
> when an ithread blocks on a mutex, so that the other handlers wouldn't be
> broken. For hardware interrupts, this would require a refcount on the
intrhand
> "interrupt source" so that the interrupt can be re-enabled when the
refcount
> hits 0. However, this is only in conceptual stage right now, and as an
> optimizaation, is a bit down the priority list.
Icky. I would have thought that there would have been an alternative way
to solving this. But let's wait until we're ready.
> --
>
> John Baldwin <jhb@FreeBSD.org> -- http://www.FreeBSD.org/~jhb/
> PGP Key: http://www.Baldwin.cx/~john/pgpkey.asc
> "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/
Later,
Bosko.
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-arch" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?B0000463571>