Date: Tue, 31 Oct 2000 23:44:06 +0000 (GMT) From: Terry Lambert <tlambert@primenet.com> To: cp@bsdi.com (Chuck Paterson) Cc: bmilekic@dsuper.net (Bosko Milekic), dillon@earth.backplane.com (Matt Dillon), freebsd-arch@FreeBSD.ORG Subject: Re: MP: per-CPU mbuf allocation lists Message-ID: <200010312344.QAA18978@usr09.primenet.com> In-Reply-To: <200010312225.PAA04504@berserker.bsdi.com> from "Chuck Paterson" at Oct 31, 2000 03:25:33 PM
next in thread | previous in thread | raw e-mail | index | archive | help
> I would really really like to encourage anyone who wants > to do this type of work to please first help get more stuff out > from under Giant so we can start getting this thing to be act > more like a SMP system and less like a MP system that can't take > interrupts in the kernel. I still have grave reservations about running Intel hardware in virtual wire mode, and/or using kernel threads to process the interrupts, as a means of getting more than one processor into the kernel at a time. No BSD or Linux approach demonstrated so far has been able to compete successfully with the NT approach of wiring network card interrupts to particular processors. I will once again point out the paper that discusses the communications latency problem in using kernel threads, and their concommitant introduction of a communication delay. Multiprocessor Scheduling with Communication Delays B. Veltman, B. J. Lageweg, J. K. Lenstra Parallel Computing, Volume 16, 1990, pages 173-182 -- 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. Sequent was able to run 32 processors at nearly full tilt, and they _had_ a Big Giant Lock. The push-down emphasis has to be on MP-safety, not on synchronization, except where it's absolutely necessary. I think the question we ought to be asking ourselves is what _can't_ be moved from the global conflict domain into the per CPU domain. I also think it's silly to object to people like Alfred picking low hanging fruit in the networking code, merely because it's low hanging: at least picking it gets it the heck out of our way. 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?200010312344.QAA18978>