From owner-freebsd-arch Fri Apr 27 10:18:16 2001 Delivered-To: freebsd-arch@freebsd.org Received: from earth.backplane.com (earth-nat-cw.backplane.com [208.161.114.67]) by hub.freebsd.org (Postfix) with ESMTP id D7EAD37B423; Fri, 27 Apr 2001 10:18:12 -0700 (PDT) (envelope-from dillon@earth.backplane.com) Received: (from dillon@localhost) by earth.backplane.com (8.11.2/8.11.2) id f3RHHGp05457; Fri, 27 Apr 2001 10:17:16 -0700 (PDT) (envelope-from dillon) Date: Fri, 27 Apr 2001 10:17:16 -0700 (PDT) From: Matt Dillon Message-Id: <200104271717.f3RHHGp05457@earth.backplane.com> To: Nate Williams Cc: "David O'Brien" , Julian Elischer , Arch@FreeBSD.ORG, Daniel Eischen Subject: Re: KSE threading support (first parts) References: <3AE71067.FF4BD029@elischer.org> <20010425110940.L1790@fw.wintelcom.net> <3AE85776.92D6BD90@elischer.org> <20010426120630.A92915@dragon.nuxi.com> <200104270015.f3R0FAi62512@earth.backplane.com> <15081.39397.944224.776391@nomad.yogotech.com> <200104271701.f3RH1Tk05185@earth.backplane.com> <15081.42735.860662.876478@nomad.yogotech.com> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG : :I read it, and this is what I hear you saying in a nutshell. : :KSEs belonging to the same process are serialized, and can not be run :concurrently. : :What I'm saying: : :KSEs belonging to the same process can be run concurrently if we have :multiple processors. : :Where did I miss what you were saying? : :Nate You seem to believe that not being able to run KSE's for the same process concurrently somehow kills the whole concept of SMP. Well, that's complete bullshit. KSE's are extremely short-running affairs in kernel mode, especially when you consider the most likely asynchronizing case (a simple blocking situation that will most commonly be in a read() or write()). Serializing them within the context of a single process will actually *IMPROVE* SMP performance, not make it worse. Running multiple kernel contexts for the same process on different cpu's concurrently means that you must now lock every single aspect of the 'current process' concept, and cannot make any assumptions whatsoever in regards to accessing elements of the current process. Well, that's just plain insane. You will wind up with so many fragging locks and mutexes in the kernel that what performance gain you might have thought you could get is now completely blown away by the locking overhead. This is another aspect of the problem you run into when you start trying to preempt a process running in the kernel arbitrarily. Suddenly all the assumptions you were able to make before that resulted in optimal code paths now must be thrown out the window and replaced with a godaweful number of locks to protect kernel contexts from unexpected interruptions. That's insane as well. You are introducing a 'solution' to a problem that doesn't exist and breaking any chance we have of getting a reliable kernel in anything less then a few years in the process. If we were writing a kernel completely from scratch we could probably construct it to allow these things, but trying to do it with the current base is impossible -- you will never get something reliable or efficient at the end of this road. Or perhaps I should phrase it: The only way you will get anything close to reliable will be to effectively revert the system to the days of the single giant lock, because you will need so many fraggin locks to deal with the consequences you might as well have a single big giant lock. -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message