From owner-freebsd-arch Tue Jan 23 10:28:55 2001 Delivered-To: freebsd-arch@freebsd.org Received: from pike.osd.bsdi.com (unknown [204.216.28.222]) by hub.freebsd.org (Postfix) with ESMTP id C149137B699 for ; Tue, 23 Jan 2001 10:28:35 -0800 (PST) Received: from foo.osd.bsdi.com (root@foo.osd.bsdi.com [204.216.28.137]) by pike.osd.bsdi.com (8.11.1/8.9.3) with ESMTP id f0NISRx48644; Tue, 23 Jan 2001 10:28:28 -0800 (PST) (envelope-from jhb@foo.osd.bsdi.com) Received: (from jhb@localhost) by foo.osd.bsdi.com (8.11.1/8.11.1) id f0NIS3026065; Tue, 23 Jan 2001 10:28:03 -0800 (PST) (envelope-from jhb) Message-ID: X-Mailer: XFMail 1.4.0 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <20010123102231.Q26076@fw.wintelcom.net> Date: Tue, 23 Jan 2001 10:28:03 -0800 (PST) Organization: BSD, Inc. From: John Baldwin To: Alfred Perlstein Subject: Re: Second zone allocator patch Cc: Dag-Erling Smorgrav , arch@FreeBSD.ORG, Bruce Evans Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG 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 -- 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