Date: Mon, 27 Aug 2001 23:21:59 -0700 From: Terry Lambert <tlambert2@mindspring.com> To: Matt Dillon <dillon@earth.backplane.com> Cc: Robert Watson <rwatson@FreeBSD.ORG>, John Baldwin <jhb@FreeBSD.ORG>, Julian Elischer <julian@elischer.org>, current@FreeBSD.ORG Subject: Re: Headsup! KSE Nay-sayers speak up! Message-ID: <3B8B3887.4E810E34@mindspring.com> References: <Pine.NEB.3.96L.1010827141515.42016P-100000@fledge.watson.org> <200108271943.f7RJhRr24275@earth.backplane.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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 work). 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... -- Terry 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?3B8B3887.4E810E34>