Date: Mon, 7 Oct 2002 19:06:10 -0700 From: Robert Clark <res03db2@verizon.net> To: Nate Lawson <nate@root.org> Cc: freebsd-arch@FreeBSD.ORG, freebsd-smp@FreeBSD.ORG Subject: Re: Running independent kernel instances on dual-Xeon/E7500 system Message-ID: <20021007190610.A31292@darkstar.gte.net> In-Reply-To: <Pine.BSF.4.21.0210061941060.5534-100000@root.org>; from nate@root.org on Sun, Oct 06, 2002 at 07:48:40PM -0700 References: <20021006115816.A28963@darkstar.gte.net> <Pine.BSF.4.21.0210061941060.5534-100000@root.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Ok, if I missed the clue boat, where does it call next? I'd like to catch it before it gets too far away. Is FreeBSD getting better on SMP? [RC] On Sun, Oct 06, 2002 at 07:48:40PM -0700, Nate Lawson wrote: > Sorry for the unhelpful first posting. I sent a more detailed letter via > private mail, recommending he look into the exokernel papers. > > My dismissiveness was due to anticipating the direction this was going, > which is nicely shown by the response below. In short, dedicated > processors for IO were used in the minicomputer days but are wasteful > nowadays when you have lightweight interrupts and/or polling when > appropriate. > > If your scheduler sucks, fix it. If a device needs extra processing > equivalent to another N Ghz CPU, the vendor will add silicon. The "S" in > SMP is for symmetric, lest we forget. > > -Nate > > On Sun, 6 Oct 2002, Robert Clark wrote: > > I've often thought it would be nice to be able to devote > > one processor to a RT style OS instance that continuous > > duty doing "throw away" work updating the display, audio, > > etc. > > > > Using a general purpose CPU for graphics and sound work > > may not result in the kinds of performance you get with > > a GPU, but I have to imagine it would have a better > > chance of encouraging "free" driver development. > > > > On the flip side, the OS instance that didn't have > > anything to do with audio/video could spend more of > > its time doing network/disk I/O, and more traditional > > duties. > > > > [RC] > > > > On Sat, Oct 05, 2002 at 02:28:04AM -0700, Terry Lambert wrote: > > > Nate Lawson wrote: > > > > On Fri, 4 Oct 2002, David Francheski wrote: > > > > > I have a dual-Xeon processor (with E7500 chipset) motherboard. > > > > > Can anybody tell me what the development effort would be to > > > > > boot and run two independent copies of the FreeBSD kernel, > > > > > one on each Xeon processor? By this I mean that an SMP > > > > > enabled kernel would not be utilized, each kernel would be UP. > > > > > > > > > > Regards, > > > > > David L. Francheski > > > > > > > > Not possible without another BIOS, PCI bus, and separate memory -- > > > > i.e. another PC. > > > > > > IPL'ing is not the same as "running". So long as you crafted the > > > memory image of the second OS and its page tables, etc., using the > > > first processor, there should be no problem running a second copy > > > of an OS on an AP, as a result of a START IPI from the BP, after > > > the code is crafted. Thus there is no need for a separate BIOS. > > > > > > > <snip> > > > > > -- > > > > > > I've personally considered pursuing the ability to run code seperately, > > > though with the same 4G address space, seperated, so as to permit > > > running a debugger against a "crashed" FreeBSD "system" running on an > > > AP, doing the debugging from the BP, as a hosted system. The cost > > > in labor would be 2-3 months of continuous work, I think... that is > > > the estimate I arrived at, when I considered the project previously. > > > Doing this certaily beats the cost of buying an ICE to get similar > > > capability. > > > > > > > > > It would be interesting to see what other people have to say on this, > > > other than "can't be done" (not to pick on you in particular, here; > > > this is the knee-jerk reaction many people have to things like this). > > > > > > -- Terry > > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > > > with "unsubscribe freebsd-smp" in the body of the message > > > > 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-smp" in the body of the message 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?20021007190610.A31292>