Date: Tue, 20 Jun 2000 12:36:47 -0700 (PDT) From: Matthew Dillon <dillon@apollo.backplane.com> To: Warner Losh <imp@village.org> Cc: freebsd-smp@FreeBSD.ORG, Greg Lehey <grog@lemis.com> Subject: Re: SMP discussion moving to freebsd-smp Message-ID: <200006201936.MAA88247@apollo.backplane.com> References: <200006201708.KAA87060@apollo.backplane.com> <200006201844.MAA70842@harmony.village.org>
next in thread | previous in thread | raw e-mail | index | archive | help
:
:In message <200006201708.KAA87060@apollo.backplane.com> Matthew Dillon writes:
:: I now have mutexes 99% working in an SP build. I will be making
:: SP (single processor) patch sets available tonight or tomorrow
:: morning. (99% == I can boot the machine normally but after a
:: while it locks up due to an interrupt nesting issue which I haven't
:: dealt with yet).
:
:May I request that you don't check in the new MP core until the SP
:issues have been resolved? I don't care if the MP boxes have major
:pain after the commit date (that's rather the point of all the new MP
:work), but have some serious issues if the SP boxes have major pain.
:It wasn't clear from the orignial message if the major pain and
:bleeding is for all users, or just MP users.
:
:It would be extremely hard to make forward progress on anything while
:the pain is there. For a few days or even a couple of weeks this
:would be OK, but for months that is not acceptible to me. I'm trying
:to get NEWCARD finished, as well as start the cardbus work and those
:...
The BSDI SMP merge work is not just an MP issue. It changes the
way the kernel operates at a fundamental level. What it means,
in short, is that the MP mechanisms are going to become 'native' to
the kernel, even for SP builds.
I'll give you an example: The SPL mechanism is inherently a
single-processor algorithm. It just doesn't work on an MP system.
Rather then hack SPL's for MP builds we are going to (eventually)
remove them entirely from the system ... SP or MP build.
So, for example, the Scheduler will no longer be protected by
splhigh()/spl0(). It will instead be protected by SchedMutex... the
same protection mechanism will be used for both the SP and MP builds.
Another example: Interrupts are going to become interrupt threads
natively (on both the SP and MP builds). This means that the kernel
must be preemptable while sitting in kernel mode. On both the SP
and MP builds.
So, as you can see, most of the mechanisms we need to implement apply
to both SP and MP builds.
This means that SP builds are going to be unstable for a while, not
just MP builds, as we work out the issues. I am fairly confident that
I can produce a stable set of changes in the first patch set, but
the fact of the matter is that much of the work is going to entail
ripping out the SPL compatibility mechanisms one at a time and replacing
them with mutexes. This will be an ongoing process over the next 6
months and that means that -current is going to be less stable for
the entire time -- for both the SP and MP builds.
:Please note, this isn't an attempt to disparage your work, or to try
:to get overly in the way of it. I'm merely trying to keep the SP
:world relatively stable while the MP work is going on. Ther'es a 6
:year tradition of having -current be basically usable for developers
:to develop in that I'd like to continue.
:
:Warner
-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?200006201936.MAA88247>