Date: Mon, 24 Jul 2000 07:43:55 -0600 From: Chuck Paterson <cp@bsdi.com> To: Greg Lehey <grog@lemis.com> Cc: Matthew Dillon <dillon@apollo.backplane.com>, Bruce Evans <bde@zeta.org.au>, David Greenman <dg@root.com>, freebsd-smp@freebsd.org Subject: Re: : ipending (was: SMP progress (was: Stepping on Toes)) Message-ID: <200007241343.HAA04677@berserker.bsdi.com>
next in thread | raw e-mail | index | archive | help
}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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200007241343.HAA04677>