Date: Mon, 30 Apr 2001 10:23:18 -0700 (PDT) From: Matt Dillon <dillon@earth.backplane.com> To: Nate Williams <nate@yogotech.com> Cc: Alfred Perlstein <bright@wintelcom.net>, Daniel Eischen <eischen@vigrid.com>, Nate Williams <nate@yogotech.com>, Julian Elischer <julian@elischer.org>, Arch@FreeBSD.ORG Subject: Re: KSE threading support (first parts) Message-ID: <200104301723.f3UHNIc36491@earth.backplane.com> References: <15081.50170.297579.938254@nomad.yogotech.com> <Pine.SUN.3.91.1010427154434.12501B-100000@pcnet1.pcnet.com> <20010427130826.G18676@fw.wintelcom.net> <15081.53821.755743.746621@nomad.yogotech.com>
next in thread | previous in thread | raw e-mail | index | archive | help
:> Being able to have threads used in a "this application wants to
:> utilize _all_ available system reasources" meaning if you have
:> more than one processor, I want to see mysql, apache, whatever
:> using it (by default!). If your model doesn't include this then
:> please don't bother continuing, the stability issues versus the
:> gain don't work for me at all.
:
:Having 'serialized' KSE's (which Matt wants) means that an application
:will be *UNABLE* to use all of the system resources, because only one
:thread in threaded application (apache, mysql, etc..) is allowed to run
:at one time, no matter how many CPU's are there.
:
:
:Nate
Nonsense. It means no such thing. You missed the whole point about
using rfork(). One application, multiple threads, MULTPLE PROCESSES
(using rfork() supporting those threads, and the kernel contexes
for ANY GIVEN PROCESS are serialized, *NOT* the kernel contexts across
all the N processes.
That is the model we discussed at Yahoo and at at least three BAFUG
meetings. That is the model that best fits the current source base.
Somebody somewhere started mangling the model into something that
sounds great on paper and in theory, but is going to be god aweful hell to
implement -- by trying to run multiple KSE's belonging to ONE
process CONCURRENTLY, you now have to lock so much shit in the kernel
that was previously contextual that you will get an across-the-board
performance drop no matter what.
-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?200104301723.f3UHNIc36491>