Date: Thu, 08 May 1997 21:23:38 +0800 From: Peter Wemm <peter@spinner.dialix.com> To: Stephen Roome <steve@visint.co.uk> Cc: Terry Lambert <terry@lambert.org>, freebsd-smp@FreeBSD.ORG Subject: Re: Where to start SMP? Message-ID: <199705081323.VAA06214@spinner.DIALix.COM> In-Reply-To: Your message of "Thu, 08 May 1997 14:04:57 %2B0100." <Pine.BSF.3.91.970508134648.21666E-100000@bagpuss.visint.co.uk>
next in thread | previous in thread | raw e-mail | index | archive | help
Stephen Roome wrote: [..] > Well, this was my point, the question then is, are there people out there > smart enough to actually write the bits of necessary evil self-modyfying > code to get something like this done so that UP and SMP are the same > kernel with run time options. Without it actually taking 100 times longer > and not actually being a 100* improvement. I doubt it, especially after > your next para. > > Personally, I think that it would be an amazing claim to have a GENERIC > kernel that could run on both UP and SMP, and utilise each hardware. Just as a BTW, the early versions of the SMP work actually did run on both uniprocessor (no apic at all), and smp motherboards with either 0 or 1 cpu present. It's not out of the question. We're having a head scratch at the moment about how best to deal with lots of interrupt sources. One thing that I have in mind might not be too difficult to have an apic-aware kernel that *also* can support the 8259 without much (if any) interrupt/spl overhead - and allow up to about 220 interrupt sources in a system without having a 256 bit interrupt mask. The problem is when we have a device that has multiple interrupt sources and when one interrupt handler has to block the others. (I'm thinking of the soundblaster type devices that have multiple components on the same card). There is a low cost way of doing this too.... (Sorry, I know that's teasing..) Just because the current unfinished work is compile time configurable, it doesn't automatically mean that the final result will be to. It's just that there are more important things to fix at the moment. > > Now as to UP vs. SMP locking: that's an isolated enough issue that > > David Miller's point about self-modifying code is a good point. But > > it would mean isolating all code up to the point of the SMP startup > > in such a way as to either not encounter locking primitivs, or, more > > likely, not encounter the hot-patch code in the boot phase, defaulting > > to one or the other, and then replacing the function pointer at the > > call address with the hot patch function. A lot of voodoo. > > A lot of headaches. It'd be great fun debugging! You said it... This (like what DEC did for their 3.0 and above releases) would solve certain run-time problems, but certainly presents a significant challenge. There are other ways around the problem too without resorting to self modifying code if we're prepared to wear the cost of a simple_lock() call to something that just does a ret for the UP case. DEC probably had it easier than we would since it's a risc cpu with probably just one subroutine call instruction - the x86 family can call subroutines in several ways and having a handler track back and figure out what code sequence that gcc generated would be a nightmare. I suspect the cost of changing a call _simple_lock to a set of nop's would be bad too - I vaguely recall something about nop being used to synchronise all pipeline execution and being quite expensive (although perhaps I'm thinking of another cpu arch). > -- > Steve Roome > Technical Systems Manager, Vision Interactive Ltd. > E: steve@visint.co.uk M: +44 (0) 976 241 342 > T: +44 (0) 117 973 0597 F: +44 (0) 117 923 8522 Cheers, -Peter
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199705081323.VAA06214>