From owner-freebsd-arch Tue Jan 23 10:55: 9 2001 Delivered-To: freebsd-arch@freebsd.org Received: from fw.wintelcom.net (ns1.wintelcom.net [209.1.153.20]) by hub.freebsd.org (Postfix) with ESMTP id A9C4337B69B; Tue, 23 Jan 2001 10:54:49 -0800 (PST) Received: (from bright@localhost) by fw.wintelcom.net (8.10.0/8.10.0) id f0NIsna04831; Tue, 23 Jan 2001 10:54:49 -0800 (PST) Date: Tue, 23 Jan 2001 10:54:48 -0800 From: Alfred Perlstein To: John Baldwin Cc: Dag-Erling Smorgrav , arch@FreeBSD.ORG, Bruce Evans Subject: Re: Second zone allocator patch Message-ID: <20010123105448.T26076@fw.wintelcom.net> References: <20010123102231.Q26076@fw.wintelcom.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from jhb@FreeBSD.ORG on Tue, Jan 23, 2001 at 10:28:03AM -0800 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG * John Baldwin [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