You need to settle dude, pre-emption isn't a goal, it's mearly a
_possible_ side effect.
We're not aiming for pre-emption, we're aiming for more concurrancy.
* Matt Dillon <[EMAIL PROTECTED]> [010417 13:51] wrote:
> :
> :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 - [[EMAIL PROTECTED]|[EMAIL PROTECTED]]
>
> 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
--
-Alfred Perlstein - [[EMAIL PROTECTED]|[EMAIL PROTECTED]]
Represent yourself, show up at BABUG http://www.babug.org/
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
