Matt Dillon wrote:
> Just for myself, I am seriously considering just throwing the whole lot
> (-current, that is) away and starting over from -stable. I spent 20 hours
> last weekend trying to unwind even part of the VM system from Giant, and
> failed utterly. I'd love to see the KSE stuff in -stable, I think it
> might even be a better fit.
> I am seriously considering this because I think we made a huge mistake
> throwing away the spl*() mechanism in -current, as a means of getting out
> from under the Giant lock paradigm quickly and partitioning the problem
> in a manner that allows subsystems to be worked on independantly. And
> I don't see any way to get it back. The spl*() mechanism already
> partitions the major subsystems that *need* to operate concurrently:
> I/O, interrupts, and the network stack. We would be able to work on
> major subsystems independantly and we would be able to debug things much
> more easily. -current as it currently stands is very nearly undebuggable.
> I've been thinking about this for the last few months... I am still
> thinking about it. I haven't made a decision yet. I think if KSEs go
> into -current I would stick with it, but if KSEs do not go into -current
> I don't see much of a point, -current will have wholely gone off in a
> direction that I don't believe in (rather then just mostly gone off).
I'm similarly hesitant about -current; I didn't really like
the SPL changes, which were capable of being converted to a
lock per mask, and getting moderately parallel code rather
cheaply... actually, I'm running my network stack almost
totally without NETISR (see the Van Jacobsen papers), and
expect to get rid of it completely in the very near future;
this eliminates the real splimp induced contention remaining,
making it safe to treat SPL's as masks of bit locks to hold.
I'm also not too enamored about the interrupt threads idea,
which I've argued before -- it has always boiled down to the
fact "it was available at the time", without respect to the
actual merits of the approach. If I have to schedule, I'm
already dead, when it comes to a receiver livelock, since I'll
just be taking interrupts until I run out of mbufs, and then
keep taking them forever, while dropping the packets that I
no longer have mbufs for, as the clients retransmit me to death.
FWIW, I've worked on several FreeBSD based embedded systems
products (Whistle was sold to IBM on the basis of one of them),
and have always used "down rev" code to ensure stability. I
doubt very much if I will go to 5.0 when/if it becomes available,
because the SMP code as is is not addressing anything but small
numbers of CPUs, and seems to be ignoring issues that would lead
to large numbers of CPUs and/or migration of processes to other
nodes within a large cluster. I don't really have faith that it
will run 80% faster on an 8-way system than it will on a 4-way,
and I expect the lack of interrupt lock-down will make it not as
sutable as a uniprocessor system for network processing when
PCIX hits general release (8Mbit/S burst rate capable).
Count me as another much more interested in the KSE work than
the SMP work that has occurred so far (with a few exceptions,
like some of the experimental code Alfred has discussed at
I'd also like to see a port of the KSE stuff to -stable, most
particularly if we are not going to see it in 5.0, but even
then, it would be useful.
I look at the SMPng stuff as "research which has yet to prove
itself", and would push that further off into the future, or
just keep the HEAD as a research branch, and bring in KSE's
on the 4.x BRANCH.
Switching to using P4 lines Of Developement before the the
SMPng started would sure have saved us a lot of pain here...
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message