Date: Mon, 3 Jul 2000 11:22:03 +0930 From: Greg Lehey <grog@lemis.com> To: Matthew Dillon <dillon@apollo.backplane.com> Cc: Chuck Paterson <cp@bsdi.com>, David Greenman <dg@root.com>, freebsd-smp@freebsd.org Subject: SMP progress (was: Stepping on Toes) Message-ID: <20000703112203.B61851@wantadilla.lemis.com> In-Reply-To: <200006271742.KAA35851@apollo.backplane.com> References: <200006261650.KAA17801@berserker.bsdi.com> <200006271742.KAA35851@apollo.backplane.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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.
>>
>> Chuck
>
> 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
--
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20000703112203.B61851>