From owner-freebsd-arch Tue Jan 23 11:46:18 2001 Delivered-To: freebsd-arch@freebsd.org Received: from guardian.marianopolis.edu (unknown [207.183.55.144]) by hub.freebsd.org (Postfix) with SMTP id DE29637B400; Tue, 23 Jan 2001 11:45:57 -0800 (PST) Received: id LAA01766; Tue, 23 Jan 2001 11:42:38 -0800 Received: by gateway id ; Tue, 23 Jan 2001 14:43:54 -0500 Message-ID: From: "Bosko Milekic" To: "John Baldwin" , "Alfred Perlstein" Cc: "Dag-Erling Smorgrav" , , "Bruce Evans" Subject: Re: Second zone allocator patch Date: Tue, 23 Jan 2001 14:43:50 -0500 X-MSMail-Priority: Normal X-Priority: 3 X-Mailer: Microsoft Internet Mail 4.70.1161 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG 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 -- 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