Date: Tue, 20 Jun 2000 12:46:30 -0700 (PDT) From: Matthew Dillon <dillon@apollo.backplane.com> To: Luoqi Chen <luoqi@watermarkgroup.com> Cc: freebsd-smp@FreeBSD.ORG, grog@lemis.com Subject: Re: SMP discussion moving to freebsd-smp Message-ID: <200006201946.MAA88405@apollo.backplane.com> References: <200006201935.e5KJZhE04172@lor.watermarkgroup.com>
next in thread | previous in thread | raw e-mail | index | archive | help
:
:> Right now the SP build works because I am allowing (unthreaded) interrupts
:> to steal the idleproc's context, and that only works because they can
:> get the giant mutex without blocking (remember, the BSDI giant mutex
:> is a blocking mutex, not a spin mutex). In the MP build the interrupts
:> need to be able to block getting the giant mutex which means we need
:> to implement heavy-weight interrupt threads at the very least before
:> we can get anything working, because we are not allowed to block in
:> the idleproc.
:>
:May I suggest we first make the giant mutex a spin mutex (as our good old
:giant kernel lock) and focus on the SP first? In the mean time, MP should
:continue to work, as only one processor is allowed in the kernel. Once the
:SP is stablized, we start to tackle the MP build.
:
:-lq
Without interrupt threads it doesn't matter whether the GiantMutex
is a spin or a blocking mutex because it will never get that far...
it will always succeed the first try in the SP build.
But we have to implement interrupt threads in order to be able to
migrate away from the SPL mechanism, and we have to do that for
both builds (rip SPL's out of the kernel entirely). This, in fact,
represents *most* of the work that is going to occur in the next
few months (ripping out SPL's and replacing them with Mutexes).
The whole thing is interrelated. The GiantMutex must be held in order
to be able to use the 'old' SPL mechanisms during the transition period.
Interrupts must be threaded in order to be able to start replacing SPL's
with mutexes. GiantMutex must be a blocking mutex to be able to
thread interrupts. Therefore the GiantMutex must be a blocking mutex.
Interrupt threads are going to be 'in' in less then a week. To delay
it would delay the entire project for the reasons outlined in the
previous paragraph.
The Schedular mutex is a spinning lock in the new design and replaces
the scheduler-aspects that the *old* spinning MP lock handled before.
However, the aspects of the old MP lock that protected entry into
the kernel (verses just the scheduler), migrates to the new blocking
GiantMutex.
-Matt
Matthew Dillon
<dillon@backplane.com>
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?200006201946.MAA88405>