Date: Tue, 17 Apr 2001 13:51:10 -0700 (PDT) From: Matt Dillon <dillon@earth.backplane.com> To: Alfred Perlstein <bright@wintelcom.net> Cc: "Justin T. Gibbs" <gibbs@scsiguy.com>, Doug Barton <DougB@DougBarton.net>, "'current@freebsd.org'" <current@FreeBSD.ORG> Subject: Re: FW: Filesystem gets a huge performance boost Message-ID: <200104172051.f3HKpAF06881@earth.backplane.com> References: <200104160259.f3G2xqs06321@aslan.scsiguy.com> <200104160616.f3G6GI973782@earth.backplane.com> <20010417011957.W976@fw.wintelcom.net> <200104171722.f3HHMpt94518@earth.backplane.com> <20010417130210.K976@fw.wintelcom.net>
next in thread | previous in thread | raw e-mail | index | archive | help
:
:There's actually very little code that non-premptable once we get the
:kernel mutexed. The least complex way to accomplish this is to only
:preempt kernel processes that hold no mutex (low level) locks.
:
:--
:-Alfred Perlstein - [bright@wintelcom.net|alfred@freebsd.org]
I wish it were that simple. Remember when we went to shared file
descriptor arrays for processes? Half a dozen serious bugs were
introduced into the kernel from that change which weren't fixed for
over a year and half. And that was *WITH* a Giant lock left intact.
A change to a single subsystem introduced 6+ serious bugs.
Now you guys are introducing preemptive kernel scheduling and expect
it will be a walk in the park? I expect it will introduce so many bugs
that the system will be destabilized for over a year, because that sort
of thing effects every single subsystem rather then just one or two.
It is not going to be as simple as throwing mutexes around every little
piece of code that might access shared state somewhere. How many
mutex calls are we going to wind up making to implement the simplest
system call now? How much overhead are we going to introduce to support
a feature that isn't going to add one iota of performance to the system?
An incredible number of very cool optimizations can be made when you
have the ability to assume that the cpu you are running under will not
get ripped out from under you. Things like per-cpu caching - not only
of mbufs or memory, but of other things as well. Simple access to
per-cpu globals now must suddenly be done with compare-exchange or
otherwise be required to use atomic instructions. None of the current
per-cpu variable handling code assumes that.
It's just not a good idea. Do you want people to adopt -current when it
becomes 5.0? It isn't going to happen if preemptive kernel scheduling
is in there. I am going to wind up having to support 4.x for the next
two years before 5.x becomes reliable enough to use in a production
environment. Or, worse, -current is going to move down a path of
no-return (becoming so unreliable that it will not be adopted by anyone)
and we are going to wind up having to scrap the whole damn thing!
I was somewhat skeptical about BSDI's interrupt-as-thread methodology,
but at least they didn't bite of more then they could chew when they
implemented it. Trying to extend that model to the Nth degree is
creating a huge mess -- and for what? Just to support interrupts as
threads? It isn't worth it.
I would much rather see us changing the interrupt model to be less
invasive, thus allowing interrupts to run unhindered as interrupts
rather then threads, rather then see this preemptive kernel scheduling
stuff go in. I love SMP, but I love stability more. BSDI focused on
the things that actually effected performance. -current is not focused
at all and is going off the deep end.. trying to do things that would
be interesting work for 5.2 or 5.3 but just plain should not be in 5.0.
-Matt
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200104172051.f3HKpAF06881>