Date: Tue, 31 Oct 2000 16:48:34 -0700 From: Chuck Paterson <cp@bsdi.com> To: Terry Lambert <tlambert@primenet.com> 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: <200010312348.QAA05579@berserker.bsdi.com> In-Reply-To: Your message of "Tue, 31 Oct 2000 23:44:06 GMT." <200010312344.QAA18978@usr09.primenet.com>
next in thread | previous in thread | raw e-mail | index | archive | help
I don't think we are going to be running the processors in virtual wire more and we won't be really using kernel threads once we get the light weight context switch code going, they are just threads if a lock blocks. As to wiring an interrupt to a given processor, there is nothing in the general implementation the prohibits this. If you can steer the interrupt to a given processor it can be handled on that processor. Chuck Terry Lambert wrote on: Tue, 31 Oct 2000 23:44:06 GMT }> 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 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?200010312348.QAA05579>