From owner-freebsd-smp Sun Jul 23 20:17: 0 2000 Delivered-To: freebsd-smp@freebsd.org Received: from wantadilla.lemis.com (wantadilla.lemis.com [192.109.197.80]) by hub.freebsd.org (Postfix) with ESMTP id 4EE6337B7B1 for ; Sun, 23 Jul 2000 20:16:46 -0700 (PDT) (envelope-from grog@wantadilla.lemis.com) Received: (from grog@localhost) by wantadilla.lemis.com (8.9.3/8.9.3) id MAA36347; Mon, 24 Jul 2000 12:45:20 +0930 (CST) (envelope-from grog) Date: Mon, 24 Jul 2000 12:45:20 +0930 From: Greg Lehey To: Matthew Dillon , Chuck Paterson , Bruce Evans Cc: David Greenman , freebsd-smp@FreeBSD.ORG Subject: : ipending (was: SMP progress (was: Stepping on Toes)) Message-ID: <20000724124520.F82241@wantadilla.lemis.com> References: <200007221620.JAA29862@apollo.backplane.com> <200007221657.KAA20309@berserker.bsdi.com> <200007051652.KAA14768@berserker.bsdi.com> <20000722185705.A10221@wantadilla.lemis.com> <200007221620.JAA29862@apollo.backplane.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.4i In-Reply-To: <200007221620.JAA29862@apollo.backplane.com>; from dillon@apollo.backplane.com on Sat, Jul 22, 2000 at 09:20:23AM -0700 Organization: LEMIS, PO Box 460, Echunga SA 5153, Australia Phone: +61-8-8388-8286 Fax: +61-8-8388-8725 Mobile: +61-418-838-708 WWW-Home-Page: http://www.lemis.com/~grog X-PGP-Fingerprint: 6B 7B C3 8C 61 CD 54 AF 13 24 52 F8 6D A4 95 EF Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Sunday, 23 July 2000 at 3:36:39 +1000, Bruce Evans wrote: > On Sat, 22 Jul 2000, Matthew Dillon wrote: > >>> In a similar way, I'm removing interrupt mask copies in memory. We >>> still mask interrupts which aren't in use, but no others. If anybody >>> has any reason not to want to do this, we should talk about it. > > That would be wrong. The interrupt masks are kept in memory because it > is much faster to access them there. Several hundred times faster than > PIC accesses on current machines. When I implemented this on 1992's > machines, the memory copies were less than ten times faster. The APIC > case is not as bad. I don't know the details of it. It wasn't my intention to retrieve them from the PIC/APIC. Certainly if we have to set interrupt masks, we'd keep copies of them in memory. More on this below. >> I think you still have to mask level interrupts, otherwise you won't >> be able to sti. Some subsystems may generate a phenominal number >> of interrupts while the interrupt routine is running -- for example, > ^^^ another >> the serial ports. > > E.g., one serial port interrupting every 87 usec gives about 50 > interrupts while the keyboard interrupt handler is busy-waiting to > program the keyboard LEDs. Ugh. Are keyboards that slow? But is that such a big problem? The interrupts occur at the same rate when no keyboard interrupt is running. The interrupt only schedules the handler thread. If it's already scheduled, it's very fast. >> I think the masking was put in there as an optmiization not >> only for that, but also so the interrupt could be EOI'd early >> so as to allow a new interrupt to become pending while the >> interrupt routine was running (thus closing a potential window >> of opportunity where an interrupt might otherwise be missed). > > This only works right for interrupts other than the one being > handled (we guarantee not to miss other interrupts provided they are > live for at least the few usec needed for interrupt processing > before the EOI). Masking the current interrupt prevents ipending > getting set for it, and there is race to exit from the interrupt > handler and clear the masks so that a new transient interrupt can be > seen before it goes away. We certainly lose this race in some > cases, e.g., when the exit is interrupted by another interrupt > handler than takes too long. I suspect that most "stray" interrupts > are caused by losing this race. On Saturday, 22 July 2000 at 10:57:40 -0600, Chuck Paterson wrote: > > When I read you mail I didn't answer because what you said > sounded right. But, what was I thinking. The short answer is Matt > is correct. > > When running in APIC mode BSD/OS uses auto EIO for the io APIC > and counts on the level which gets set in the local APIC to mask > interrupts while the handler is running. The local APIC gets and EIO > when the handler is finished. If the thread blocks then the > interrupt get masked in hardware if it is a level triggered and in > all cases it gets EIO'd. Given that you are just doing heavy weight > interrupts this is the equivalent of blocking on an interrupt and > you will always need to mask at least level triggered interrupts and > EIO them. > > Matt's comment about bunches of extra level triggered > interrupts being a problem is something that is going to have to be > looked into with BSD/OS. The reason we don't mask the interrupts now > is that doing the actual masking operation is soooo expensive. I > suspect we will want to mark which edge triggered interrupts we > which to mask. OK, I've been thinking about this. I've also looked at the tapes taken at Yahoo! last month, which I'm currently copying. There you (Chuck) stated that one of the main goals of SMPng was the elimination of masking interrupts. Matt stated then that it wouldn't work like that, but we didn't finish the discussion. We should probably do it now. My understanding is that the threaded interrupt stuff splits interrupts (potentially) into two separate processing steps: 1. Receiving the interrupt, handling the PIC/APIC, and scheduling an interrupt thread. 2. Processing the interrupt thread. I understand that we would do (1) immediately and (2) when we have time for it, but as quickly as possible. Sure, while we're handling a slow operation like the keyboard LEDs, a lot of other interrupts can come in. But the interrupt rate won't change, the serial interrupts still come in at 11.5 kHz. All that happens there is that step (1) will be executed each time, just like it would be at any other time. The other issue is that we should potentially be able to handle one interrupt in one processor and another in a different processor. I know that there are problems in this attitude, and that we have deferred it, but I can't see how this can work at all if we mask the interrupts. Looking at the code we have at the moment, the "slow" interrupts write two values to the PIC, one to set the mask and one to EOI, before processing the interrupt, and another after the interrupt to unmask the interrupt: Xintr3: pushl $0 push a dummy error code pushl $0 and a dummy trap type pushal save general registers pushl %ds save segment registers pushl %es pushl %fs mov $KDSEL, %ax mov %ax,%ds and point to kernel data segment mov %ax,%es mov %ax,%fs movb imen + (irq_num >> 3), %al get the correct byte of the mask register orb $(1 << (irq_num % 8)), %al and set the corresponding bit in %al movb %al,imen + (irq_num >> 3) store it back outb %al,$ICU_IMR and set it in the ICU mask register movb $0x20, %al EOI OCW outb %al,$ICU enable the ICU movl cpl, %eax get the current priority level testb $(1 << (irq_num % 8)), %al are we masking it in software? jne 2f yes: just note it's pending incb intr_nesting_level note one more nested interrupt Xresume3: incl cnt + 0xc note another global interrupt movl intr_countp + irq_num * 4,%eax point to interrupt count incl (%eax) and increment it movl cpl, %eax get CPL again pushl %eax save on the stack pushl intr_unit + irq_num * 4 unit number for this IRQ orl intr_mask + irq_num * 4,%eax mask for this IRQ movl %eax,cpl is the new CPL sti reenable interrupts call *intr_handler + irq_num * 4 call handler (unit) cli disable interrupts again movb imen + (irq_num >> 3), %al get the interrupt mask andb $~(1 << (irq_num % 8)), %al unmask this interrupt movb %al,imen + (irq_num >> 3) save new mask outb %al,$ICU_IMR and set the ICU mask sti enable interrupts again jmp doreti and return from the interrupt This happens on every interrupt, and as Bruce points out, the writes take a long time. By comparison, the code I have now is much shorter and contains only the minimum 1 outb instruction: Xintr3: pushl $0 pushl $0 pushal pushl %ds pushl %es pushl %fs mov $0x10 ,%ax mov %ax,%ds mov %ax,%es mov %ax,%fs movb $0x20 ,%al outb %al,$0x020 incb intr_nesting_level Xresume3: pushl 3 IRQ number sti call sched_ithd jmp doreti sched_ithd is pretty close to the BSD/OS code. I've left the debugging code and some comments out of this version: void sched_ithd(void *cookie) { int irq; irq = (int) cookie; ithd *ir = ithds[irq]; /* find our process */ cnt.v_intr++; /* one more global interrupt */ intr_countp[irq]++; /* one more for this IRQ */ ir->it_need = 1; mtx_enter(&sched_lock, MTX_SPIN); if (ir->it_run == 0) { ir->it_run = 2; setrunqueue(ir->it_proc); aston(); } mtx_exit(&sched_lock, MTX_SPIN); aston(); /* ??? check priorities first? */ } The issue here, of course, is taking the scheduler lock. It seems to me that we can avoid taking it if we first set it_need and then check it_run and find it set, but I haven't thought through all the possible race conditions there. Suggestions are welcome. Anyway, to get back to the original issue: as Bruce observes, the I/O operations are very slow compared with instruction execution. I'd hope that this alternative would give us a performance boost. Greg -- Finger grog@lemis.com for PGP public key See complete headers for address and phone numbers To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Mon Jul 24 1:10:11 2000 Delivered-To: freebsd-smp@freebsd.org Received: from mailman.zeta.org.au (mailman.zeta.org.au [203.26.10.16]) by hub.freebsd.org (Postfix) with ESMTP id 9E0E037B506 for ; Mon, 24 Jul 2000 01:09:57 -0700 (PDT) (envelope-from bde@zeta.org.au) Received: from bde.zeta.org.au (bde.zeta.org.au [203.2.228.102]) by mailman.zeta.org.au (8.8.7/8.8.7) with ESMTP id SAA13160; Mon, 24 Jul 2000 18:09:21 +1000 Date: Mon, 24 Jul 2000 18:09:18 +1000 (EST) From: Bruce Evans X-Sender: bde@besplex.bde.org To: Greg Lehey Cc: Matthew Dillon , Chuck Paterson , David Greenman , freebsd-smp@FreeBSD.ORG Subject: Re: : ipending (was: SMP progress (was: Stepping on Toes)) In-Reply-To: <20000724124520.F82241@wantadilla.lemis.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Mon, 24 Jul 2000, Greg Lehey wrote: > On Sunday, 23 July 2000 at 3:36:39 +1000, Bruce Evans wrote: > > On Sat, 22 Jul 2000, Matthew Dillon wrote: > >> I think you still have to mask level interrupts, otherwise you won't > >> be able to sti. Some subsystems may generate a phenominal number > >> of interrupts while the interrupt routine is running -- for example, > > ^^^ another > >> the serial ports. > > > > E.g., one serial port interrupting every 87 usec gives about 50 > > interrupts while the keyboard interrupt handler is busy-waiting to > > program the keyboard LEDs. > > Ugh. Are keyboards that slow? But is that such a big problem? The Yes, keyboards are slow, and keyboard LED programming is sloppy. All PIO devices doing large i/o's or busy waiting have the same problem (perhaps for only hundreds of usec instead of several msec). Other examples: IDE drives in PIO mode and the printer driver. > interrupts occur at the same rate when no keyboard interrupt is > running. The interrupt only schedules the handler thread. If it's > already scheduled, it's very fast. The point is that we must do lots of fiddling with the PIC to allow the keyboard interrupt handler/thread to be interrupted at all. > On Saturday, 22 July 2000 at 10:57:40 -0600, Chuck Paterson wrote: > > > > When I read you mail I didn't answer because what you said > > sounded right. But, what was I thinking. The short answer is Matt > > is correct. > > ... > > Matt's comment about bunches of extra level triggered > > interrupts being a problem is something that is going to have to be > > looked into with BSD/OS. The reason we don't mask the interrupts now > > is that doing the actual masking operation is soooo expensive. I > > suspect we will want to mark which edge triggered interrupts we level? > > which to mask. FreeBSD does some lazy masking of interrupts in the SMP case. I think this amounts to detecting which interrupts should be masked, masking them after they repeat, and then forgetting that they should have been masked before they repeat. > My understanding is that the threaded interrupt stuff splits > interrupts (potentially) into two separate processing steps: > > 1. Receiving the interrupt, handling the PIC/APIC, and scheduling an > interrupt thread. > > 2. Processing the interrupt thread. > > I understand that we would do (1) immediately and (2) when we have > time for it, but as quickly as possible. Sure, while we're handling a > slow operation like the keyboard LEDs, a lot of other interrupts can > come in. But the interrupt rate won't change, the serial interrupts > still come in at 11.5 kHz. All that happens there is that step (1) > will be executed each time, just like it would be at any other time. Except for fast interrupts, up to 99% of the overhead for step (1) is currently avoided by not touching the PIC. This shouldn't change (on i386's). This is not very portable. I'm not sure about the APIC case, and i386-PIC style fast interrupts are not implementable in general. E.g., suppose interrupts masks are actually levels and the clock interrupt is hardwired to a level higher than that of serial interrupts. Then fast (serial) interrupts can't interrupt slow (clock) interrupts. This is essentially the default state for the PIC, with the hardwiring especially braindamaged, and we fiddle with the PIC masks to get away from it. > The other issue is that we should potentially be able to handle one > interrupt in one processor and another in a different processor. I > know that there are problems in this attitude, and that we have > deferred it, but I can't see how this can work at all if we mask the > interrupts. Yes, concurrency is limited by the number of hardware interrupt priority levels or bits in the hardware interrupt masks. > Looking at the code we have at the moment, the "slow" interrupts write > two values to the PIC, one to set the mask and one to EOI, before More precisely: - one to set the mask in the slave PIC if irq >= 8 - one to set the mask in the master PIC - one to send EOI to the slave PIC if irq >= 8 and not AUTO_EOI_2 - one to send EOI to the master PIC if not AUTO_EOI_1 > processing the interrupt, and another after the interrupt to unmask > the interrupt: More precisely: - one to clear the mask in the slave PIC if irq >= 8 - one to clear the mask in the master PIC > This happens on every interrupt, and as Bruce points out, the writes > take a long time. By comparison, the code I have now is much shorter > and contains only the minimum 1 outb instruction: > > Xintr3: > pushl $0 > pushl $0 > pushal > pushl %ds > pushl %es > pushl %fs > mov $0x10 ,%ax > mov %ax,%ds > mov %ax,%es > mov %ax,%fs > movb $0x20 ,%al > outb %al,$0x020 > incb intr_nesting_level > Xresume3: > pushl 3 IRQ number > sti > call sched_ithd > jmp doreti But this doesn't actually work. It fails in most cases for level triggered interrupts and works in most cases for edge triggered interrupts. With level triggered interrupts that stay on, it gives endless recursion after the "sti". With edge triggered interrupts, the recursion may be limited by the hardware not toggling the irq too often. The lazy masking that I mentioned above avoids the setting the (A)PIC masks initially by detecting the recursion and recovering from it by setting the masks later, etc. It can almost be used to simplify the code as above. Unfortunately, this ends up being more complicated, of course. Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Mon Jul 24 6:45:15 2000 Delivered-To: freebsd-smp@freebsd.org Received: from berserker.bsdi.com (berserker.twistedbit.com [199.79.183.1]) by hub.freebsd.org (Postfix) with ESMTP id 5B75537B914 for ; Mon, 24 Jul 2000 06:45:10 -0700 (PDT) (envelope-from cp@berserker.bsdi.com) Received: from berserker.bsdi.com (cp@LOCALHOST [127.0.0.1]) by berserker.bsdi.com (8.9.3/8.9.3) with ESMTP id HAA04677; Mon, 24 Jul 2000 07:43:55 -0600 (MDT) Message-Id: <200007241343.HAA04677@berserker.bsdi.com> To: Greg Lehey Cc: Matthew Dillon , Bruce Evans , David Greenman , freebsd-smp@freebsd.org Subject: Re: : ipending (was: SMP progress (was: Stepping on Toes)) From: Chuck Paterson Date: Mon, 24 Jul 2000 07:43:55 -0600 Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org }OK, I've been thinking about this. I've also looked at the tapes }taken at Yahoo! last month, which I'm currently copying. There you }(Chuck) stated that one of the main goals of SMPng was the elimination }of masking interrupts. Matt stated then that it wouldn't work like }that, but we didn't finish the discussion. We should probably do it }now. There were several things which got munged into one here. There is the issue of SPLS, lazy interrupt, and ipending. BSD/OS does not do any of this and I don't believe you want to. There are 2 cases of actually blocking, both of which must be done in hardware. Only the first of which is dealt with today in BSD/OS. The first case is where there is a level triggered interrupt which can not be completed at the time you get it. This has to blocked in hardware. The second is to block fast edge triggered interrupts which re-occur. This also has to be blocked in hardware. In typically operation running on the APIC BSD/OS doesn't have to mask anything. Missing a mutex in the bottom half of a level triggered interrupt is obviously going to require that it gets masked in order to do the EOI. This also requires that a mutex is gotten to protect the hardware and any software state you have. Currently BSD/OS uses the sched lock for this as it is generally already held when the masks and hardware is manipulated. Given that you are only implementing heavy weight threads you will always have to block the interrupts now. You really ought to organize the assembly code keeping in mind what will be happening when you do lite weight threads, or else all the code you are doing now is going to be tossed in the next go around. Masking needs to be disassociated from actually taking the interrupt. I realize that I may not have explicitly said this before. Ipending is effectively replaced by the runlock/scheduled state of a thread. }The other issue is that we should potentially be able to handle one }interrupt in one processor and another in a different processor. I }know that there are problems in this attitude, and that we have }deferred it, but I can't see how this can work at all if we mask the }interrupts. I don't understand the issue you have with this, it ought to "just work". Masking is done in hardware, and you have to acquired a mutex to protect the hardware while you touch it. The mask you are setting is out in the IO APIC so it protects both processors. On a related note, in APIC mode BSD/OS doesn't quite assign interrupt threads, or block interrupt "right". Sources are still grouped by the interrupt level they had in PIC mode, where they should really be broken out into sources available to the pins on the APIC. I have not personally looked to see how much of a mess this is to fix, so I wouldn't advocate that we necessarily want do this with FreeBSD now. The reason I bring it up is to point out the potential problems storing to much of this state in something like say an int. BSD/OS does retain the old PIC stuff, and the information indicating that a mask has to be undone is held in an int. The actual masks are else where and we could as easily have stored this info with the mask, and probably should have. Once we undo the ties to the old PIC stuff in APIC mode I'm sure this will have to be undone. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Mon Jul 24 9:17: 3 2000 Delivered-To: freebsd-smp@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by hub.freebsd.org (Postfix) with ESMTP id 4C6A137BA02 for ; Mon, 24 Jul 2000 09:16:53 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id JAA41009; Mon, 24 Jul 2000 09:16:43 -0700 (PDT) (envelope-from dillon) Date: Mon, 24 Jul 2000 09:16:43 -0700 (PDT) From: Matthew Dillon Message-Id: <200007241616.JAA41009@apollo.backplane.com> To: Greg Lehey Cc: Chuck Paterson , Bruce Evans , David Greenman , freebsd-smp@FreeBSD.ORG Subject: Re: : ipending (was: SMP progress (was: Stepping on Toes)) References: <200007221620.JAA29862@apollo.backplane.com> <200007221657.KAA20309@berserker.bsdi.com> <200007051652.KAA14768@berserker.bsdi.com> <20000722185705.A10221@wantadilla.lemis.com> <200007221620.JAA29862@apollo.backplane.com> <20000724124520.F82241@wantadilla.lemis.com> Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org :This happens on every interrupt, and as Bruce points out, the writes :take a long time. By comparison, the code I have now is much shorter :and contains only the minimum 1 outb instruction: : :Xintr3: : pushl $0 : pushl $0 : pushal : pushl %ds : pushl %es : pushl %fs : mov $0x10 ,%ax : mov %ax,%ds : mov %ax,%es : mov %ax,%fs : movb $0x20 ,%al : outb %al,$0x020 : incb intr_nesting_level :Xresume3: : pushl 3 IRQ number : sti : call sched_ithd : jmp doreti : :sched_ithd is pretty close to the BSD/OS code. I've left the :debugging code and some comments out of this version: This will fail utterly. First, it will fail for level triggered interrupts. Second, there is a massive race condition if a new interrupt occurs while the interrupt thread is already running... in that case the interrupt thread will not be restarted when it is through processing the first one (for the same interrupt source). Easily half of our interrupt routines expect that to work properly. The ipending stuff in my code sample takes care of that case, as does the current masking code. I would strongly recommend that you not spend time trying to optimize the already reasonably optimal interrupt masking. I've gone over that code a hundred times in the last year (because I don't like the mess either), but frankly there is no way to do it better. And I'm sure Bruce has too. -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Mon Jul 24 9:40:13 2000 Delivered-To: freebsd-smp@freebsd.org Received: from thelab.hub.org (nat193.142.mpoweredpc.net [142.177.193.142]) by hub.freebsd.org (Postfix) with ESMTP id B0D9837B580; Mon, 24 Jul 2000 09:40:08 -0700 (PDT) (envelope-from scrappy@hub.org) Received: from localhost (scrappy@localhost) by thelab.hub.org (8.9.3/8.9.3) with ESMTP id NAA84988; Mon, 24 Jul 2000 13:38:05 -0300 (ADT) (envelope-from scrappy@hub.org) X-Authentication-Warning: thelab.hub.org: scrappy owned process doing -bs Date: Mon, 24 Jul 2000 13:38:05 -0300 (ADT) From: The Hermit Hacker To: freebsd-questions@freebsd.org Cc: freebsd-smp@freebsd.org Subject: Need to compare FreeBSD -> Solaris 8 ... Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Morning all ... I have this box sitting around idle right now ... 1Gig of RAM, several 9 gig scsi hard drives ... no OS. I'm going to install FreeBSD 4.x on it this afternoon and want to run a load of tests on it and save the results ... benchmark the disk I/O, memory, SMP capabilities, network I/O, etc ... basically, I want to compare the two OSs on the exact same hardware, and see how they compare ... but I need suggestions on what software I should be running for doing the benchmarking ... it has to be apples to apples ... iozone-freebsd vs iozone-solaris, etc ... Since there doesn't appear to be one already, I'll compile my results and put them up on a web page for everyone to see and comment upon ... suggestions? thanks ... Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy Systems Administrator @ hub.org primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Mon Jul 24 12: 9:58 2000 Delivered-To: freebsd-smp@freebsd.org Received: from turtle.looksharp.net (cc360882-a.strhg1.mi.home.com [24.2.221.22]) by hub.freebsd.org (Postfix) with ESMTP id F1FA737BE96; Mon, 24 Jul 2000 12:09:32 -0700 (PDT) (envelope-from bsdx@looksharp.net) Received: from localhost (bsdx@localhost) by turtle.looksharp.net (8.9.3/8.9.3) with ESMTP id PAA63523; Mon, 24 Jul 2000 15:09:26 -0400 (EDT) (envelope-from bsdx@looksharp.net) Date: Mon, 24 Jul 2000 15:09:26 -0400 (EDT) From: Adam To: The Hermit Hacker Cc: freebsd-questions@FreeBSD.ORG, freebsd-smp@FreeBSD.ORG Subject: Re: Need to compare FreeBSD -> Solaris 8 ... In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Mon, 24 Jul 2000, The Hermit Hacker wrote: > >Morning all ... > > I have this box sitting around idle right now ... 1Gig of RAM, >several 9 gig scsi hard drives ... no OS. > > I'm going to install FreeBSD 4.x on it this afternoon and want to >run a load of tests on it and save the results ... benchmark the disk I/O, >memory, SMP capabilities, network I/O, etc ... basically, I want to >compare the two OSs on the exact same hardware, and see how they compare >... > > but I need suggestions on what software I should be running for >doing the benchmarking ... it has to be apples to apples >... iozone-freebsd vs iozone-solaris, etc ... > > Since there doesn't appear to be one already, I'll compile my >results and put them up on a web page for everyone to see and comment upon >... Is that legal? Check the license for Solaris.. > > suggestions? thanks ... > >Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy >Systems Administrator @ hub.org >primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org > > > >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 From owner-freebsd-smp Mon Jul 24 12:17:36 2000 Delivered-To: freebsd-smp@freebsd.org Received: from thelab.hub.org (nat193.142.mpoweredpc.net [142.177.193.142]) by hub.freebsd.org (Postfix) with ESMTP id 8FF4A37BD9E; Mon, 24 Jul 2000 12:17:31 -0700 (PDT) (envelope-from scrappy@hub.org) Received: from localhost (scrappy@localhost) by thelab.hub.org (8.9.3/8.9.3) with ESMTP id QAA08639; Mon, 24 Jul 2000 16:14:54 -0300 (ADT) (envelope-from scrappy@hub.org) X-Authentication-Warning: thelab.hub.org: scrappy owned process doing -bs Date: Mon, 24 Jul 2000 16:14:54 -0300 (ADT) From: The Hermit Hacker To: Adam Cc: freebsd-questions@FreeBSD.ORG, freebsd-smp@FreeBSD.ORG Subject: Re: Need to compare FreeBSD -> Solaris 8 ... In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Mon, 24 Jul 2000, Adam wrote: > On Mon, 24 Jul 2000, The Hermit Hacker wrote: > > > > >Morning all ... > > > > I have this box sitting around idle right now ... 1Gig of RAM, > >several 9 gig scsi hard drives ... no OS. > > > > I'm going to install FreeBSD 4.x on it this afternoon and want to > >run a load of tests on it and save the results ... benchmark the disk I/O, > >memory, SMP capabilities, network I/O, etc ... basically, I want to > >compare the two OSs on the exact same hardware, and see how they compare > >... > > > > but I need suggestions on what software I should be running for > >doing the benchmarking ... it has to be apples to apples > >... iozone-freebsd vs iozone-solaris, etc ... > > > > Since there doesn't appear to be one already, I'll compile my > >results and put them up on a web page for everyone to see and comment upon > >... > > Is that legal? Check the license for Solaris.. D'oh ... never thought about that, but now that you do mention it, most likely it isn't *sigh* God, I hate commercial software :( Welp, there goes that plan ... inhouse use only :( To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Mon Jul 24 13:13:17 2000 Delivered-To: freebsd-smp@freebsd.org Received: from fw.wintelcom.net (ns1.wintelcom.net [209.1.153.20]) by hub.freebsd.org (Postfix) with ESMTP id B096737B630 for ; Mon, 24 Jul 2000 13:13:12 -0700 (PDT) (envelope-from bright@fw.wintelcom.net) Received: (from bright@localhost) by fw.wintelcom.net (8.10.0/8.10.0) id e6OKDCN10331 for smp@freebsd.org; Mon, 24 Jul 2000 13:13:12 -0700 (PDT) Date: Mon, 24 Jul 2000 13:13:12 -0700 From: Alfred Perlstein To: smp@freebsd.org Subject: atomic queues. Message-ID: <20000724131311.W13979@fw.wintelcom.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.4i Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org I've been digging through a lot of books looking for an implementation of atomic queues that I could have sworn I've seen. So far I haven't had any luck except for re-implementing them: enqueue: do { cmpval = list_head; mynode->next = cmpval; } while (compare_and_exchange(&listhead, cmpval, mynode) != cmpval); The idea is that we read the list head pointer, then we assign our node to be enqueued's next pointer to the head of the list. If a compare and exchanges detects that the head node hasn't changed since we read the list_head and list_head->next then we're safe. dequeue (allocate): do { mynode = list_head; newhead = list_head->next; } while (compare_and_exchange(&listhead, mynode, newhead) != mynode); We swap the list head with list_head->next but only succeed if list_head hasn't changed since we read list_head->next. Does anyone have any references online or pointer to some text that discuss this? -- -Alfred Perlstein - [bright@wintelcom.net|alfred@freebsd.org] "I have the heart of a child; I keep it in a jar on my desk." To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Mon Jul 24 13:23:29 2000 Delivered-To: freebsd-smp@freebsd.org Received: from thelab.hub.org (nat193.142.mpoweredpc.net [142.177.193.142]) by hub.freebsd.org (Postfix) with ESMTP id D67B237B5FA; Mon, 24 Jul 2000 13:23:21 -0700 (PDT) (envelope-from scrappy@hub.org) Received: from localhost (scrappy@localhost) by thelab.hub.org (8.9.3/8.9.3) with ESMTP id RAA39039; Mon, 24 Jul 2000 17:21:10 -0300 (ADT) (envelope-from scrappy@hub.org) X-Authentication-Warning: thelab.hub.org: scrappy owned process doing -bs Date: Mon, 24 Jul 2000 17:21:10 -0300 (ADT) From: The Hermit Hacker To: Jeremiah Gowdy Cc: Adam , freebsd-questions@FreeBSD.ORG, freebsd-smp@FreeBSD.ORG Subject: Re: Need to compare FreeBSD -> Solaris 8 ... In-Reply-To: <000201bff5aa$dd3162f0$0100000a@netfinity> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Mon, 24 Jul 2000, Jeremiah Gowdy wrote: > > > > but I need suggestions on what software I should be running for > > > >doing the benchmarking ... it has to be apples to apples > > > >... iozone-freebsd vs iozone-solaris, etc ... > > > > > > > > Since there doesn't appear to be one already, I'll compile my > > > >results and put them up on a web page for everyone to see and comment > upon > > > >... > > > > > > Is that legal? Check the license for Solaris.. > > > > D'oh ... never thought about that, but now that you do mention it, most > > likely it isn't *sigh* God, I hate commercial software :( > > > > Welp, there goes that plan ... inhouse use only :( > > > It's not legal to benchmark two OSes and post the results ? Since when ? > That seems like BS to me. If that's true, the freedoms in this country are > already gone. Actually, from reading reports of benchmarking that the SQUID folks did and posted awhile back, several vendors have this "don't post results" policy ... I think it falls under "if we look good, go for it, but if we look bad, we'll sue your proverbial ass off" ... To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Mon Jul 24 13:26:46 2000 Delivered-To: freebsd-smp@freebsd.org Received: from cs.rice.edu (cs.rice.edu [128.42.1.30]) by hub.freebsd.org (Postfix) with ESMTP id 55C1037B51C for ; Mon, 24 Jul 2000 13:26:42 -0700 (PDT) (envelope-from alc@cs.rice.edu) Received: (from alc@localhost) by cs.rice.edu (8.9.0/8.9.0) id PAA05907; Mon, 24 Jul 2000 15:26:36 -0500 (CDT) Date: Mon, 24 Jul 2000 15:26:35 -0500 From: Alan Cox To: Alfred Perlstein Cc: smp@freebsd.org Subject: Re: atomic queues. Message-ID: <20000724152635.B6184@cs.rice.edu> References: <20000724131311.W13979@fw.wintelcom.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.5us In-Reply-To: <20000724131311.W13979@fw.wintelcom.net>; from Alfred Perlstein on Mon, Jul 24, 2000 at 01:13:12PM -0700 Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Mon, Jul 24, 2000 at 01:13:12PM -0700, Alfred Perlstein wrote: > I've been digging through a lot of books looking for an implementation > of atomic queues that I could have sworn I've seen. So far I haven't > had any luck except for re-implementing them: > Do a search for lock-free data structures. (Also, wait-free data structures. They are slightly different things.) Here's a good starting point: http://www.cs.brown.edu/people/mph/ Alan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Mon Jul 24 19:59: 4 2000 Delivered-To: freebsd-smp@freebsd.org Received: from berserker.bsdi.com (berserker.twistedbit.com [199.79.183.1]) by hub.freebsd.org (Postfix) with ESMTP id 7646F37B8BC for ; Mon, 24 Jul 2000 19:59:00 -0700 (PDT) (envelope-from cp@berserker.bsdi.com) Received: from berserker.bsdi.com (cp@[127.0.0.1]) by berserker.bsdi.com (8.9.3/8.9.3) with ESMTP id UAA02299; Mon, 24 Jul 2000 20:55:33 -0600 (MDT) Message-Id: <200007250255.UAA02299@berserker.bsdi.com> To: Greg Lehey Cc: freebsd-smp@freebsd.org Subject: com interrupts and heavy weight threads From: Chuck Paterson Date: Mon, 24 Jul 2000 20:55:33 -0600 Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Greg, Concerning the discussion a while ago on the benefits of having com and other such interrupts always run in a borrowed context. I do agree that you will want to end up running these interrupts always in a borrowed context. But, you may want to actually run these as heavy weight interrupts when you first start. Here's the deal. I don't think this was explicitly mentioned but if you use a borrowed context you have to get the low level com driver locked up (mutices installed and working) in order to boot at all. There isn't a half way step of running this code under the Giant lock. You wouldn't want/need to change the driver structure at all during this phase, just get the stuff to run. If I were doing this I think I would go ahead and lock up the com driver, but until I looked at it some I'm not sure. This is more to make sure you are aware of the issue than to influence the decision you arrive at. Chuck To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Mon Jul 24 20:13: 4 2000 Delivered-To: freebsd-smp@freebsd.org Received: from c014.sfo.cp.net (c014-h014.c014.sfo.cp.net [209.228.12.78]) by hub.freebsd.org (Postfix) with SMTP id 586CC37BBA8 for ; Mon, 24 Jul 2000 20:12:53 -0700 (PDT) (envelope-from dchance@valuedata.net) Received: (cpmta 20647 invoked from network); 24 Jul 2000 20:12:52 -0700 Date: 24 Jul 2000 20:12:52 -0700 Message-ID: <20000725031252.20646.cpmta@c014.sfo.cp.net> X-Sent: 25 Jul 2000 03:12:52 GMT Received: from [209.83.193.158] by mail.valuedata.net with HTTP; 24 Jul 2000 20:12:52 PDT Content-Type: text/plain Content-Disposition: inline Mime-Version: 1.0 To: questions@freebsd.org From: dchance@valuedata.net Cc: bsdx@looksharp.net, freebsd-questions@FreeBSD.ORG, freebsd-smp@FreeBSD.ORG X-Mailer: Web Mail 3.6.5.3 Subject: Re: Need to compare FreeBSD -> Solaris 8 ... Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org looks like someone has read your mind already :) this was posted on slashdot http://innominate.org/%7Etgr/slides/performance/ it compares OpenBSD, FreeBSD, Solaris, Linux, and a couple others I believe. That what you're looking for? Daryl Chance On Mon, 24 July 2000, The Hermit Hacker wrote: > > On Mon, 24 Jul 2000, Adam wrote: > > > On Mon, 24 Jul 2000, The Hermit Hacker wrote: > > > > > > > >Morning all ... > > > > > > I have this box sitting around idle right now ... 1Gig of RAM, > > >several 9 gig scsi hard drives ... no OS. > > > > > > I'm going to install FreeBSD 4.x on it this afternoon and want to > > >run a load of tests on it and save the results ... benchmark the disk I/O, > > >memory, SMP capabilities, network I/O, etc ... basically, I want to > > >compare the two OSs on the exact same hardware, and see how they compare > > >... > > > > > > but I need suggestions on what software I should be running for > > >doing the benchmarking ... it has to be apples to apples > > >... iozone-freebsd vs iozone-solaris, etc ... > > > > > > Since there doesn't appear to be one already, I'll compile my > > >results and put them up on a web page for everyone to see and comment upon > > >... > > > > Is that legal? Check the license for Solaris.. > > D'oh ... never thought about that, but now that you do mention it, most > likely it isn't *sigh* God, I hate commercial software :( > > Welp, there goes that plan ... inhouse use only :( > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-questions" in the body of the message To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Mon Jul 24 20:14:13 2000 Delivered-To: freebsd-smp@freebsd.org Received: from wantadilla.lemis.com (wantadilla.lemis.com [192.109.197.80]) by hub.freebsd.org (Postfix) with ESMTP id 1151937B696 for ; Mon, 24 Jul 2000 20:14:00 -0700 (PDT) (envelope-from grog@wantadilla.lemis.com) Received: (from grog@localhost) by wantadilla.lemis.com (8.9.3/8.9.3) id MAA08252; Tue, 25 Jul 2000 12:43:25 +0930 (CST) (envelope-from grog) Date: Tue, 25 Jul 2000 12:43:25 +0930 From: Greg Lehey To: Chuck Paterson Cc: freebsd-smp@freebsd.org Subject: Re: com interrupts and heavy weight threads Message-ID: <20000725124325.G98476@wantadilla.lemis.com> References: <200007250255.UAA02299@berserker.bsdi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.4i In-Reply-To: <200007250255.UAA02299@berserker.bsdi.com>; from cp@bsdi.com on Mon, Jul 24, 2000 at 08:55:33PM -0600 Organization: LEMIS, PO Box 460, Echunga SA 5153, Australia Phone: +61-8-8388-8286 Fax: +61-8-8388-8725 Mobile: +61-418-838-708 WWW-Home-Page: http://www.lemis.com/~grog X-PGP-Fingerprint: 6B 7B C3 8C 61 CD 54 AF 13 24 52 F8 6D A4 95 EF Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Monday, 24 July 2000 at 20:55:33 -0600, Chuck Paterson wrote: > Greg, > Concerning the discussion a while ago on the benefits of > having com and other such interrupts always run in a borrowed > context. > > I do agree that you will want to end up running these > interrupts always in a borrowed context. But, you may want to > actually run these as heavy weight interrupts when you first start. > Here's the deal. I don't think this was explicitly mentioned but if > you use a borrowed context you have to get the low level com driver > locked up (mutices installed and working) in order to boot at all. > There isn't a half way step of running this code under the Giant > lock. You wouldn't want/need to change the driver structure at all > during this phase, just get the stuff to run. > > If I were doing this I think I would go ahead and lock up the > com driver, but until I looked at it some I'm not sure. This is > more to make sure you are aware of the issue than to influence the > decision you arrive at. Thanks for the information, Chuck. I originally intended to register only certain interrupts as threads, then it appeared too complicated and I changed my mind, but now I'm coming back to that view. I'm currently fairly well through the startup sequence, and I'm finding that my blocked interrupt mask (yes, you were all right, of course I needed one) is getting set incorrectly. The trouble is, with 100 clock interrupts a second, it's rather difficult to test it in the kernel debugger. So I'll go back and incorporate both kinds of interrupts. Based on this, I'd say I'll leave the clock and serial I/O interrupts in the old style. Everybody: I've been asked to provide the source files for perusal. I think it's a bit early for that, but I can understand the interest. As a result, I've put the entire work tree up on the web at http://www.lemis.com/SMPng/. Please don't download everything; this is a 56 kB modem link, and it would set fire to the line. If you do want to do more than browse at the moment, please contact me and we'll arrange something. Greg -- Finger grog@lemis.com for PGP public key See complete headers for address and phone numbers To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Tue Jul 25 1:19: 3 2000 Delivered-To: freebsd-smp@freebsd.org Received: from wantadilla.lemis.com (wantadilla.lemis.com [192.109.197.80]) by hub.freebsd.org (Postfix) with ESMTP id 7827937B840 for ; Tue, 25 Jul 2000 01:18:57 -0700 (PDT) (envelope-from grog@wantadilla.lemis.com) Received: (from grog@localhost) by wantadilla.lemis.com (8.9.3/8.9.3) id RAA44514 for FreeBSD-smp@FreeBSD.org; Tue, 25 Jul 2000 17:48:54 +0930 (CST) (envelope-from grog) Date: Tue, 25 Jul 2000 17:48:54 +0930 From: Greg Lehey To: FreeBSD SMP list Subject: Progress with interrupt threads Message-ID: <20000725174854.I98476@wantadilla.lemis.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.4i Organization: LEMIS, PO Box 460, Echunga SA 5153, Australia Phone: +61-8-8388-8286 Fax: +61-8-8388-8725 Mobile: +61-418-838-708 WWW-Home-Page: http://www.lemis.com/~grog X-PGP-Fingerprint: 6B 7B C3 8C 61 CD 54 AF 13 24 52 F8 6D A4 95 EF Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org I have now finished coding the interrupt threads, and am trying to debug them. As mentioned in an earlier message, the sources are available for perusal at http://www.lemis.com/SMPng/. Please don't download everything; this is a 56 kB modem link, and it would set fire to the line. If you do want to do more than browse at the moment, please contact me and we'll arrange something. Following Chuck's suggestion and my own intention in my last message, I first made the sio and clock interrupts fast interrupts, which are not threaded; instead, the interrupt handler is executed before EOI. In this configuration, the system hung in the IDE probe. I then changed the disk drivers to also be fast interrupts, which allowed the IDE driver to continue, but the system still hangs in the SCSI probes. Since it gets through the IDE probes OK, I'm migrating to a system without SCSI, which will take a few hours to install. In the meantime, if you see anything obviously wrong in the code, please let me know. On the positive side, the scheduling seems to work, and the keyboard interrupt seems to work OK. Greg -- Finger grog@lemis.com for PGP public key See complete headers for address and phone numbers To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Tue Jul 25 8:12:57 2000 Delivered-To: freebsd-smp@freebsd.org Received: from Ilsa.StevesCafe.com (Ilsa.StevesCafe.com [206.168.13.65]) by hub.freebsd.org (Postfix) with ESMTP id D0C7037B57D for ; Tue, 25 Jul 2000 08:12:53 -0700 (PDT) (envelope-from fbsd@Ilsa.StevesCafe.com) Received: from Ilsa.StevesCafe.com (localhost [127.0.0.1]) by Ilsa.StevesCafe.com (8.9.3/8.9.3) with ESMTP id JAA88155; Tue, 25 Jul 2000 09:12:40 -0600 (MDT) (envelope-from fbsd@Ilsa.StevesCafe.com) Message-Id: <200007251512.JAA88155@Ilsa.StevesCafe.com> X-Mailer: exmh version 2.0.2 2/24/98 From: Steve Passe To: Greg Lehey Cc: FreeBSD SMP list Subject: Re: Progress with interrupt threads In-reply-to: Your message of "Tue, 25 Jul 2000 17:48:54 +0930." <20000725174854.I98476@wantadilla.lemis.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 25 Jul 2000 09:12:40 -0600 Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hi, > I have now finished coding the interrupt threads, and am trying to > debug them. As mentioned in an earlier message, the sources are > available for perusal at http://www.lemis.com/SMPng/. Please don't > download everything; this is a 56 kB modem link, and it would set fire > to the line. If you do want to do more than browse at the moment, > please contact me and we'll arrange something. Is there any reason you can't place them on freefall? -- Steve Passe | powered by smp@csn.net | Symmetric MultiProcessor FreeBSD To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Tue Jul 25 16:19:28 2000 Delivered-To: freebsd-smp@freebsd.org Received: from wantadilla.lemis.com (wantadilla.lemis.com [192.109.197.80]) by hub.freebsd.org (Postfix) with ESMTP id EE00537BA62 for ; Tue, 25 Jul 2000 16:19:24 -0700 (PDT) (envelope-from grog@wantadilla.lemis.com) Received: (from grog@localhost) by wantadilla.lemis.com (8.9.3/8.9.3) id IAA45806; Wed, 26 Jul 2000 08:49:14 +0930 (CST) (envelope-from grog) Date: Wed, 26 Jul 2000 08:49:14 +0930 From: Greg Lehey To: Steve Passe Cc: FreeBSD SMP list Subject: Re: Progress with interrupt threads Message-ID: <20000726084914.O98476@wantadilla.lemis.com> References: <20000725174854.I98476@wantadilla.lemis.com> <200007251512.JAA88155@Ilsa.StevesCafe.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.4i In-Reply-To: <200007251512.JAA88155@Ilsa.StevesCafe.com>; from smp@csn.net on Tue, Jul 25, 2000 at 09:12:40AM -0600 Organization: LEMIS, PO Box 460, Echunga SA 5153, Australia Phone: +61-8-8388-8286 Fax: +61-8-8388-8725 Mobile: +61-418-838-708 WWW-Home-Page: http://www.lemis.com/~grog X-PGP-Fingerprint: 6B 7B C3 8C 61 CD 54 AF 13 24 52 F8 6D A4 95 EF Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Tuesday, 25 July 2000 at 9:12:40 -0600, Steve Passe wrote: > Hi, > >> I have now finished coding the interrupt threads, and am trying to >> debug them. As mentioned in an earlier message, the sources are >> available for perusal at http://www.lemis.com/SMPng/. Please don't >> download everything; this is a 56 kB modem link, and it would set fire >> to the line. If you do want to do more than browse at the moment, >> please contact me and we'll arrange something. > > Is there any reason you can't place them on freefall? No. Once they're in any reasonable shape, we'll commit them. In the meantime, it doesn't seem to be worth the trouble. Greg -- Finger grog@lemis.com for PGP public key See complete headers for address and phone numbers To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Tue Jul 25 16:28: 1 2000 Delivered-To: freebsd-smp@freebsd.org Received: from feral.com (feral.com [192.67.166.1]) by hub.freebsd.org (Postfix) with ESMTP id E5EC937BAE5 for ; Tue, 25 Jul 2000 16:27:56 -0700 (PDT) (envelope-from mjacob@feral.com) Received: from semuta.feral.com (semuta [192.67.166.70]) by feral.com (8.9.3/8.9.3) with ESMTP id QAA31618; Tue, 25 Jul 2000 16:27:44 -0700 Date: Tue, 25 Jul 2000 16:27:05 -0700 (PDT) From: Matthew Jacob Reply-To: mjacob@feral.com To: Greg Lehey Cc: FreeBSD SMP list Subject: Re: Progress with interrupt threads In-Reply-To: <20000726084914.O98476@wantadilla.lemis.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org No alpha implementation code? -matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Tue Jul 25 17:35:39 2000 Delivered-To: freebsd-smp@freebsd.org Received: from wantadilla.lemis.com (wantadilla.lemis.com [192.109.197.80]) by hub.freebsd.org (Postfix) with ESMTP id 2C8BE37B6E4 for ; Tue, 25 Jul 2000 17:35:31 -0700 (PDT) (envelope-from grog@wantadilla.lemis.com) Received: (from grog@localhost) by wantadilla.lemis.com (8.9.3/8.9.3) id KAA79972; Wed, 26 Jul 2000 10:05:20 +0930 (CST) (envelope-from grog) Date: Wed, 26 Jul 2000 10:05:20 +0930 From: Greg Lehey To: Matthew Jacob Cc: FreeBSD SMP list Subject: Re: Progress with interrupt threads Message-ID: <20000726100520.C55913@wantadilla.lemis.com> References: <20000726084914.O98476@wantadilla.lemis.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.4i In-Reply-To: ; from mjacob@feral.com on Tue, Jul 25, 2000 at 04:27:05PM -0700 Organization: LEMIS, PO Box 460, Echunga SA 5153, Australia Phone: +61-8-8388-8286 Fax: +61-8-8388-8725 Mobile: +61-418-838-708 WWW-Home-Page: http://www.lemis.com/~grog X-PGP-Fingerprint: 6B 7B C3 8C 61 CD 54 AF 13 24 52 F8 6D A4 95 EF Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Tuesday, 25 July 2000 at 16:27:05 -0700, Matt Jacob wrote: > > No alpha implementation code? Not yet. Also (ironically) no SMP code. Let's get the stuff working on i386 SP first. Greg -- Finger grog@lemis.com for PGP public key See complete headers for address and phone numbers To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Tue Jul 25 17:36:20 2000 Delivered-To: freebsd-smp@freebsd.org Received: from feral.com (feral.com [192.67.166.1]) by hub.freebsd.org (Postfix) with ESMTP id 8B2EE37BC03 for ; Tue, 25 Jul 2000 17:36:14 -0700 (PDT) (envelope-from mjacob@feral.com) Received: from semuta.feral.com (semuta [192.67.166.70]) by feral.com (8.9.3/8.9.3) with ESMTP id RAA31833; Tue, 25 Jul 2000 17:36:06 -0700 Date: Tue, 25 Jul 2000 17:35:26 -0700 (PDT) From: Matthew Jacob Reply-To: mjacob@feral.com To: Greg Lehey Cc: FreeBSD SMP list Subject: Re: Progress with interrupt threads In-Reply-To: <20000726100520.C55913@wantadilla.lemis.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Fair enough. On Wed, 26 Jul 2000, Greg Lehey wrote: > On Tuesday, 25 July 2000 at 16:27:05 -0700, Matt Jacob wrote: > > > > No alpha implementation code? > > Not yet. Also (ironically) no SMP code. Let's get the stuff working > on i386 SP first. > > Greg > -- > Finger grog@lemis.com for PGP public key > See complete headers for address and phone numbers > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Wed Jul 26 11:53:53 2000 Delivered-To: freebsd-smp@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 558) id AD38F37B9C6; Wed, 26 Jul 2000 11:53:51 -0700 (PDT) To: bright@wintelcom.net, smp@freebsd.org Subject: Re: atomic queues. In-Reply-To: <20000724131311.W13979@fw.wintelcom.net> Message-Id: <20000726185351.AD38F37B9C6@hub.freebsd.org> Date: Wed, 26 Jul 2000 11:53:51 -0700 (PDT) From: hsu@FreeBSD.ORG (Jeffrey Hsu) Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org The standard paper everyone has to read in graduate OS classes on this is Michael Greenwald, The Synergy Between Non-blocking Synchronization and Operating System Structure http://www.cs.berkeley.edu/~brewer/cs262/NonBlocking.ps To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message