From owner-freebsd-arch Tue Oct 31 15:44:28 2000 Delivered-To: freebsd-arch@freebsd.org Received: from smtp04.primenet.com (smtp04.primenet.com [206.165.6.134]) by hub.freebsd.org (Postfix) with ESMTP id 65D7937B4C5 for ; Tue, 31 Oct 2000 15:44:26 -0800 (PST) Received: (from daemon@localhost) by smtp04.primenet.com (8.9.3/8.9.3) id QAA15727; Tue, 31 Oct 2000 16:41:11 -0700 (MST) Received: from usr09.primenet.com(206.165.6.209) via SMTP by smtp04.primenet.com, id smtpdAAAIhayBE; Tue Oct 31 16:40:59 2000 Received: (from tlambert@localhost) by usr09.primenet.com (8.8.5/8.8.5) id QAA18978; Tue, 31 Oct 2000 16:44:07 -0700 (MST) From: Terry Lambert Message-Id: <200010312344.QAA18978@usr09.primenet.com> Subject: Re: MP: per-CPU mbuf allocation lists To: cp@bsdi.com (Chuck Paterson) Date: Tue, 31 Oct 2000 23:44:06 +0000 (GMT) Cc: bmilekic@dsuper.net (Bosko Milekic), dillon@earth.backplane.com (Matt Dillon), freebsd-arch@FreeBSD.ORG In-Reply-To: <200010312225.PAA04504@berserker.bsdi.com> from "Chuck Paterson" at Oct 31, 2000 03:25:33 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 > 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