From owner-freebsd-smp Tue Jun 20 12:37:49 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 8D49C37BFB6 for ; Tue, 20 Jun 2000 12:37:44 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id MAA88247; Tue, 20 Jun 2000 12:36:47 -0700 (PDT) (envelope-from dillon) Date: Tue, 20 Jun 2000 12:36:47 -0700 (PDT) From: Matthew Dillon Message-Id: <200006201936.MAA88247@apollo.backplane.com> To: Warner Losh Cc: freebsd-smp@FreeBSD.ORG, Greg Lehey Subject: Re: SMP discussion moving to freebsd-smp References: <200006201708.KAA87060@apollo.backplane.com> <200006201844.MAA70842@harmony.village.org> Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org : :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 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message