Date: Thu, 6 Jul 2000 23:51:08 +0000 (GMT) From: Terry Lambert <tlambert@primenet.com> To: bright@wintelcom.net (Alfred Perlstein) Cc: tlambert@primenet.com (Terry Lambert), grog@lemis.com (Greg Lehey), jeroen@vangelderen.org (Jeroen C. van Gelderen), eischen@vigrid.com (Daniel Eischen), jasone@canonware.com (Jason Evans), luoqi@watermarkgroup.com (Luoqi Chen), smp@FreeBSD.ORG Subject: Re: SMP meeting summary Message-ID: <200007062351.QAA08404@usr02.primenet.com> In-Reply-To: <20000705162925.V25571@fw.wintelcom.net> from "Alfred Perlstein" at Jul 05, 2000 04:29:26 PM
next in thread | previous in thread | raw e-mail | index | archive | help
> > > The idea is that the a quantum is actually so great that there's > > > little chance of one of the wake_all processes colliding on the > > > lock. > > > > This is a bogus idea, both in the case of a large number of > > processors, and in quantum ownership case. > > You are correct in that it's bogus for _large_ number of processors, > but for small numbers it makes a lot of sense. It would work nicely > if one could attempt to schedule the processes in order that they > were unblocked. What's small? > Even on system with a signifigant amount of CPUs, sssuming the > system is busy, then between actually scheduling these thundering > processes on other CPUs and having them run there will be enough > time to avoid another pileup on the mutex. > > If the CPUs are not busy and collisions occur, well then the > collisions are free because we have cycles to burn. :) This is not a safe assumption; consider the case of a distributed cluster which supported migration. High communications latencies between processors are destructive. Equally, on low latency communications links, such as in a 4-way Xeon system, the amount of interprocessor contention on cache line invalidation is significant. If there isn't such conetntion, why lock it? If there is such contention, why take the invalidation hit for all processors, instead of (on average) 1.5? From a research perspective, consider the case of goal-based computing, goal-based computing where the participants have incomplete information, and cooperative robotics. These are fields of research where your simplification will make use of BSD impossible. > > The quantum ownership case is "so long as I have work to do, if > > the scheduler gave me a quantum, it's my damn quantum!". In other > > words, the idea of voluntary preemption or semivoluntary preenption, > > such as one might get when the system makes a process block merely > > because it has made a system call that can't be immediately > > satisfied. A multithreaded of FSA process doesn't care about a > > single blocking context: it wants to use the remainder of its > > quantum. > > I'm not sure I understand this nor how it applies. A multithreaded file system architecture could be used to implement a concurrent "team" type program, which transfered data from one region in a contention domain to another. If that were implemented using your approach, there would by lockstep read/write/read/write, rather than concurrent operation with a single latency (e.g. read/write+read/write+read/.../write). This is the moral equivalent of a sliding window for data copies on contention domains, involving two processors. One of the basic flaws of SVR4 based Dynix for a very long time (and perhaps still; I haven't been inside a Sequent box for 2 years now) was that the FSA was not multithreaded. If you want a more prosaic example, take any web server you currently operate, and replace the GIF images with CGI's that invoke the "team" program to stream the data out to the requester, instead of delivering the image directly. Note the almost 170% improvement in download time for the pages (this is the same reason that "sendfile" is a stupid idea, given that it can never achieve this improvement becuase it can never achieve this concurrency, even if you could send all the data in the UNIX disk format). 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-smp" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200007062351.QAA08404>