From owner-freebsd-arch Tue Oct 31 16:11: 6 2000 Delivered-To: freebsd-arch@freebsd.org Received: from smtp05.primenet.com (smtp05.primenet.com [206.165.6.135]) by hub.freebsd.org (Postfix) with ESMTP id 6051337B479 for ; Tue, 31 Oct 2000 16:11:04 -0800 (PST) Received: (from daemon@localhost) by smtp05.primenet.com (8.9.3/8.9.3) id RAA02202; Tue, 31 Oct 2000 17:11:32 -0700 (MST) Received: from usr09.primenet.com(206.165.6.209) via SMTP by smtp05.primenet.com, id smtpdAAAFmaOke; Tue Oct 31 17:11:19 2000 Received: (from tlambert@localhost) by usr09.primenet.com (8.8.5/8.8.5) id RAA19817; Tue, 31 Oct 2000 17:10:47 -0700 (MST) From: Terry Lambert Message-Id: <200011010010.RAA19817@usr09.primenet.com> Subject: Re: MP: per-CPU mbuf allocation lists To: bmilekic@dsuper.net (Bosko Milekic) Date: Wed, 1 Nov 2000 00:10:47 +0000 (GMT) Cc: tlambert@primenet.com (Terry Lambert), freebsd-arch@FreeBSD.ORG In-Reply-To: from "Bosko Milekic" at Oct 31, 2000 06:57:50 PM X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > On the other hand, we know that significant concurrency can > > be achieved, even with a single Big Giant Lock, by removing > > resources from the conflict domain, rather than moving them > > to private conflict domains. Per CPU resources simply do not > > need locking or mutexes or atomic_t or similar protection: > > they are inherently MP-safe. > > Is this 100% accurate? Don't we still need to protect even the > per-CPU lists with a lock just in case we get an interrupt and get > rescheduled because of a higher priority thread that wants execution? Is > this possible? Are you assuming kernel threads with kernel preemption in interrupt context? If so, why? Kernel threads make interrupt processing times non-deterministic, so it's not like you could build a hard real time system with them in there: HRT needs determinism, or you can't do scheduling or deadlining. If you don't have HRT requirements, why do you need kernel preemption? You also never do allocations while in interrupt context (unless you're SVR4). I really don't think that you can end up with self-conteded resources. > If it isn't the case, then ignore the question, but if it is, I agree > that it still makes sense to have per-CPU resources available, just > because it the lock contention is minimized. It's not just minimized, it's totally eliminated, except in the cases where you have to go back to the well and drain or fill a per CPU pool. For that, you can grab the BGL. The only contended resources are things which are intrinsically stuck in the global space, like the directory vnode for /. For those, you mutex and reference count, as necessary (Dynix FS's were non-reentrant for a long while; it was one of their biggest warts: they didn't have the mutex capability on a per object basis... that had to wait for SVR4 ES/MP [4.0.2]). Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message