From owner-freebsd-smp Sun Dec 3 14:56:17 2000 From owner-freebsd-smp@FreeBSD.ORG Sun Dec 3 14:56:14 2000 Return-Path: Delivered-To: freebsd-smp@freebsd.org Received: from mobile.wemm.org (adsl-64-163-195-99.dsl.snfc21.pacbell.net [64.163.195.99]) by hub.freebsd.org (Postfix) with ESMTP id 4BE7437B400; Sun, 3 Dec 2000 14:56:13 -0800 (PST) Received: from netplex.com.au (localhost [127.0.0.1]) by mobile.wemm.org (8.11.1/8.11.1) with ESMTP id eB3Mu7D37126; Sun, 3 Dec 2000 14:56:11 -0800 (PST) (envelope-from peter@netplex.com.au) Message-Id: <200012032256.eB3Mu7D37126@mobile.wemm.org> X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: John Baldwin Cc: Greg Lehey , smp@FreeBSD.ORG, Jake Burkholder Subject: Re: BSD/OS interrupt code In-Reply-To: <200011280601.WAA36325@john.baldwin.cx> Date: Sun, 03 Dec 2000 14:56:07 -0800 From: Peter Wemm Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org John Baldwin wrote: > > On 28-Nov-00 Greg Lehey wrote: > > On Monday, 27 November 2000 at 10:33:05 -0800, John Baldwin wrote: > >> > >> On 26-Nov-00 Jake Burkholder wrote: > >>> Hi, > >>> > >>> If anyone with access to the BSD/OS code is interested, I've written > >>> a little program that runs their interrupt stub code generator in > >>> userland. You can then abort(); and disassemble the stub from > >>> the core dump to look at the code all in one piece. Makes it much > >>> easier to follow. > >>> > >>> In case you haven't looked, their interrupt handlers are generated > >>> by bcopy-ing various blocks of assembler code into an array at > >>> runtime, and then poking in arguments and relocating branches. > >> > >> Hmm. The best way to do this probably is to have stubs with psuedo-reloca tion > >> information. I.e., have 1 stub interrupt handler template for each type ( fast, > >> threaded, fast apic, threaded apic, etc.), then have a "relocation" table on > >> the side that specifies offsets in the code that should receive one of a n umber > >> of things: vector number, vector address, etc. Alternatively, we could st ore > >> all of that info in a struct (gee, we already do with intrhand :)) and jus t > >> have the code always dereference a pointer to that struct and have the > >> relocation entries simply point to places that that pointer should be writ ten. > >> Granted, on sparc this could get much uglier (based on my understanding of > >> relocation address on sparc since an address can be formed across several > >> instructions. Yuck.) > > > > I assume you're talking about doing this at run time, presumably from > > a function like inthand_add. This is a nice, structured way to do > > things. One of the parameters might be the type of interrupt, so > > instead of three stubs for each possible interrupt, we'd only have > > one. Why didn't we do that from the start? Because it's slower. No, > > I haven't tried to prove this, but I'm pretty sure you'd have > > difficulties getting it small enough. > > > > One alternative would be to really create the entire interrupt handler > > stub in inthand_add. It's not as difficult as it probably sounds, but > > in general I agree with Bruce that the saving is probably not worth > > it. > > Doing this would be a pain as Chuck kindly pointed out. One not so difficult step > that can be taken is to make the stubs smaller and have them use more code in > common. For example, you could probably reduce the per-interrupt source port ion > of the stub to just 'pusha; mov $irq_num, %eax; jmp common_code;' in the x86 case. > However, the savings wouldn't be but so great. Nevertheless, it's something I > may play with at some point in time. The sole reason that I can think of to do this is a good one... If we have got more than 24 interrupt sources, there are *EXTENSIVE* modifications to the code required - no less than about 8 or 10 tables, lists, etc needed updating. (I changed this from 24 to 32 on one of my checked out trees, but have not committed it yet). What about machines down the track that have more than that still? One machine that I have at work has something like 10 or 12 PCI slots, with each PCI slot IRQ pin wired to an APIC pin where possible. Mostly it is A and B on the 64 bit/66MHz PCI slots that have two IRQs per slot. Suppose the two APICs had 24 pins, that is 48 interrupt sources.. That is more than I could fit in because of the _apic_imen 32 bit active mask cache. Supporting 48 irq sources, plus potentially the 16 on the PIC in parallel gives us 64 possible IRQ sources, plus the two local cpu interrupt source pins (2*ncpu), that can add up to a few. Now, have a "slow" and "fast" interrupt stub for each and we've easily got up to a theoretical 144 interrupt handler stubs on a 4-cpu system, of which *at least half will be wasted* because a handler is either slow or fast, not both. I guess a multi-gigabyte RAM 4-way or 8-way cpu with multiple APIC's isn't going to notice 72 wasted IRQ stubs, but to make this generic (remember, it cannot be easily ifdefed due to the 32 bit problem), then in order to run in that configuration we'd need to build it into the code for all systems... You could be sure that some magazine will want to do benchmarks on such a high-end system some day and we'd be caught out if we dont support it without extensive code modifications.. ("The benchmarks can only be run on released OS's" etc). Sure, machines of this configuration are not common (yet?), but by the same token, "640k ought to be enough for everybody". Cheers, -Peter -- Peter Wemm - peter@FreeBSD.org; peter@yahoo-inc.com; peter@netplex.com.au "All of this is for nothing if we don't go to the stars" - JMS/B5 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message