Date: Fri, 27 Apr 2001 10:17:16 -0700 (PDT) From: Matt Dillon <dillon@earth.backplane.com> To: Nate Williams <nate@yogotech.com> Cc: "David O'Brien" <obrien@FreeBSD.ORG>, Julian Elischer <julian@elischer.org>, Arch@FreeBSD.ORG, Daniel Eischen <eischen@vigrid.com> Subject: Re: KSE threading support (first parts) Message-ID: <200104271717.f3RHHGp05457@earth.backplane.com> 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>
next in thread | previous in thread | raw e-mail | index | archive | help
:
: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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200104271717.f3RHHGp05457>