Date: Wed, 1 Nov 2000 00:10:47 +0000 (GMT) From: Terry Lambert <tlambert@primenet.com> To: bmilekic@dsuper.net (Bosko Milekic) Cc: tlambert@primenet.com (Terry Lambert), freebsd-arch@FreeBSD.ORG Subject: Re: MP: per-CPU mbuf allocation lists Message-ID: <200011010010.RAA19817@usr09.primenet.com> In-Reply-To: <Pine.BSF.4.21.0010311854240.37200-100000@jehovah.technokratis.com> from "Bosko Milekic" at Oct 31, 2000 06:57:50 PM
next in thread | previous in thread | raw e-mail | index | archive | help
> > 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200011010010.RAA19817>