atom feed28 messages in org.freebsd.freebsd-smpSMP progress (was: Stepping on Toes)
FromSent OnAttachments
Matthew DillonJun 23, 2000 11:36 am 
David GreenmanJun 24, 2000 9:10 pm 
Matthew DillonJun 25, 2000 10:24 am 
Jake BurkholderJun 25, 2000 11:19 am 
Chuck PatersonJun 26, 2000 9:50 am 
Matthew DillonJun 27, 2000 10:41 am 
Chuck PatersonJun 27, 2000 11:19 am 
Kevin Van MarenJun 29, 2000 1:52 pm 
Greg LeheyJul 2, 2000 6:51 pm 
Jason EvansJul 3, 2000 8:41 am 
Jake BurkholderJul 3, 2000 1:14 pm 
Jake BurkholderJul 5, 2000 2:23 am 
Matthew DillonJul 5, 2000 9:43 am 
Chuck PatersonJul 5, 2000 9:52 am 
Chuck PatersonJul 5, 2000 9:57 am 
Luoqi ChenJul 5, 2000 10:29 am 
Matthew DillonJul 5, 2000 11:28 am 
Greg LeheyJul 5, 2000 4:20 pm 
Doug RabsonJul 6, 2000 1:26 am 
Matthew DillonJul 6, 2000 10:43 am 
Greg LeheyJul 22, 2000 2:26 am 
Matthew DillonJul 22, 2000 9:20 am 
Chuck PatersonJul 22, 2000 9:57 am 
Bruce EvansJul 22, 2000 10:36 am 
Greg LeheyJul 23, 2000 8:14 pm 
Bruce EvansJul 24, 2000 1:08 am 
Chuck PatersonJul 24, 2000 6:43 am 
Matthew DillonJul 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
List:org.freebsd.freebsd-smp

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.

Any comments?

Greg

To Unsubscribe: send mail to majo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message