Date: Tue, 23 Jan 2001 10:54:48 -0800 From: Alfred Perlstein <bright@wintelcom.net> To: John Baldwin <jhb@FreeBSD.ORG> Cc: Dag-Erling Smorgrav <des@ofug.org>, arch@FreeBSD.ORG, Bruce Evans <bde@zeta.org.au> Subject: Re: Second zone allocator patch Message-ID: <20010123105448.T26076@fw.wintelcom.net> In-Reply-To: <XFMail.010123102803.jhb@FreeBSD.org>; from jhb@FreeBSD.ORG on Tue, Jan 23, 2001 at 10:28:03AM -0800 References: <20010123102231.Q26076@fw.wintelcom.net> <XFMail.010123102803.jhb@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
* John Baldwin <jhb@FreeBSD.ORG> [010123 10:28] wrote: > > 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. Spinlocks don't protect against interrupts on a different CPU, unless the resource is protected by that spinlock properly. I actually think I ment spl here, but I'm on my second day on 'the patch' so your guess is as good as mine. :) > > > 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. Hmm, sort of like my suggestion at BAFUG but slower and with more context switches? :) I really don't think you want multiple hardware interrupts, but having multiple software interrupts is needed to provide SMP scalability of the network stack. -- -Alfred Perlstein - [bright@wintelcom.net|alfred@freebsd.org] "I have the heart of a child; I keep it in a jar on my desk." 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?20010123105448.T26076>