From owner-freebsd-smp  Tue Jun 20 12:47: 5 2000
Delivered-To: freebsd-smp@freebsd.org
Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2])
	by hub.freebsd.org (Postfix) with ESMTP id 85CA737BBFB
	for <freebsd-smp@FreeBSD.ORG>; Tue, 20 Jun 2000 12:47:02 -0700 (PDT)
	(envelope-from dillon@apollo.backplane.com)
Received: (from dillon@localhost)
	by apollo.backplane.com (8.9.3/8.9.1) id MAA88405;
	Tue, 20 Jun 2000 12:46:30 -0700 (PDT)
	(envelope-from dillon)
Date: Tue, 20 Jun 2000 12:46:30 -0700 (PDT)
From: Matthew Dillon <dillon@apollo.backplane.com>
Message-Id: <200006201946.MAA88405@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
References:  <200006201935.e5KJZhE04172@lor.watermarkgroup.com>
Sender: owner-freebsd-smp@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.org


:
:>     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