|Matthew Dillon||Jun 23, 2000 11:36 am|
|David Greenman||Jun 24, 2000 9:10 pm|
|Matthew Dillon||Jun 25, 2000 10:24 am|
|Jake Burkholder||Jun 25, 2000 11:19 am|
|Chuck Paterson||Jun 26, 2000 9:50 am|
|Matthew Dillon||Jun 27, 2000 10:41 am|
|Chuck Paterson||Jun 27, 2000 11:19 am|
|Kevin Van Maren||Jun 29, 2000 1:52 pm|
|Greg Lehey||Jul 2, 2000 6:51 pm|
|Jason Evans||Jul 3, 2000 8:41 am|
|Jake Burkholder||Jul 3, 2000 1:14 pm|
|Jake Burkholder||Jul 5, 2000 2:23 am|
|Matthew Dillon||Jul 5, 2000 9:43 am|
|Chuck Paterson||Jul 5, 2000 9:52 am|
|Chuck Paterson||Jul 5, 2000 9:57 am|
|Luoqi Chen||Jul 5, 2000 10:29 am|
|Matthew Dillon||Jul 5, 2000 11:28 am|
|Greg Lehey||Jul 5, 2000 4:20 pm|
|Doug Rabson||Jul 6, 2000 1:26 am|
|Matthew Dillon||Jul 6, 2000 10:43 am|
|Greg Lehey||Jul 22, 2000 2:26 am|
|Matthew Dillon||Jul 22, 2000 9:20 am|
|Chuck Paterson||Jul 22, 2000 9:57 am|
|Bruce Evans||Jul 22, 2000 10:36 am|
|Greg Lehey||Jul 23, 2000 8:14 pm|
|Bruce Evans||Jul 24, 2000 1:08 am|
|Chuck Paterson||Jul 24, 2000 6:43 am|
|Matthew Dillon||Jul 24, 2000 9:16 am|
|Subject:||SMP progress (was: Stepping on Toes)|
|From:||Greg Lehey (gr...@lemis.com)|
|Date:||Jul 2, 2000 6:51:41 pm|
On Tuesday, 27 June 2000 at 10:42:20 -0700, Matthew Dillon wrote:
Even with interrupt threads we have the GiantMutex issue... the same issue that we have with our current MP implementation. We cannot remove SPL's until we remove the GiantMutex, and we cannot remove GiantMutex without major modifications to just about every single source file in sys/
In general this isn't true. If you get to the point where
1) All entrance to unsafe code is proteced by Giant. 2) Tsleep and friend if any release Giant when they a process is suspended and re-acquire it on exit 3) Interrupts have a context to run in. 4) You have one or more scheduling locks.
Then you can just turn spls into a nop. There is lots of hand waving in regards to details at this point. BSD/OS SMPng is the existance proof.
It seems like one of the major problems in retaining spls during the change over period is that they don't much useful, and effectively push everything under Giant.
Grabbing a spl will only block interrupts, it will not give any protection against an interrupt thread which has already started.
This means that any device which might be blocked by splbio() can not be brought out from under the Giant lock until all instances of splbio have been removed.
Yes, I see it. I agree. You don't even need to hold a scheduling lock... all you need to hold is Giant.
#1 - done #2 - done #3 - (Greg) #4 - not required
I don't understand #4. I thought you had done this.
Right this moment the requirement is that only someone holding Giant is allowed to mess with spl*()'s (the cpl variable can only be messed with by people holding Giant).
At this moment, without interrupt threads, interrupts can share Giant with the curproc they interrupted. This is how our existing MP stuff worked already.
When Greg moves interrupts to their own threads, and obtains Giant to run those interrupts, no more sharing will occur and just the fact that the interrupt is holding Giant guarentees that nobody else will be messing with SPLs, thus the SPLs can be removed entirely.
Agreed. I'm in the process of implementing the heavy-weight interrupt processes now. I've just taken a look at your web page and note that the URL no longer exists; in conjunction with the discussion above, I'm no longer sure how far you are. Are you importing the BSD/OS code now?
We should probably take the rest of this offline, but I wanted to discuss how we do things. My idea is:
1. You import the BSD/OS mutexes. 2. I import/implement the heavy-weight interrupt code, which I will endeavour to get working relatively reliably. This should be a fallback while I break^H^H^H^H^Himplement light-wait interrupt threads. 3. You and I test our stuff together until it can stay up for an hour or so (exact time to be determined by Jason, who'll be carrying the can). 4. We commit the marginally stable stuff. 5. I carry on working on the light-weight threads.
-- Finger gr...@lemis.com for PGP public key See complete headers for address and phone numbers
To Unsubscribe: send mail to majo...@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message