Date: Tue, 23 Jan 2001 10:28:03 -0800 (PST) From: John Baldwin <jhb@FreeBSD.ORG> To: 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: <XFMail.010123102803.jhb@FreeBSD.org> In-Reply-To: <20010123102231.Q26076@fw.wintelcom.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On 23-Jan-01 Alfred Perlstein wrote: > > Correct me if I'm wrong... > > In 5.0 we actually have 3 states: > 1) running > 2) sleeping > 3) blocked on a mutex > > Afaik, top half (user syscalls) can be in 1, 2 or 3. However > interrupts should only be 1 or 3. Correct. > Therefore the old trick of having 'non-blocking' code to > provide interrupts with stable 'foo*' doesn't work anymore > and mutexes are needed (or at least spinlocks), but even > with spinlocks, you may still have an interrupt or user > context come in on another CPU. Erm, spinlocks protect against preemption. > 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 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. -- 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/ 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?XFMail.010123102803.jhb>