Date: Sat, 17 Apr 2004 18:48:43 -0400 From: "Brian F. Feldman" <green@freebsd.org> To: Brian Fundakowski Feldman <green@freebsd.org>, arch@freebsd.org Subject: Re: kqueue giant-locking (&kq_Giant, locking) Message-ID: <200404172248.i3HMmiVI042942@green.homeunix.org> In-Reply-To: Message from John-Mark Gurney <gurney_j@efn.org> of "Sat, 17 Apr 2004 15:14:42 PDT." <20040417221442.GW567@funkthat.com>
next in thread | previous in thread | raw e-mail | index | archive | help
John-Mark Gurney <gurney_j@efn.org> wrote: > Brian Fundakowski Feldman wrote this message on Fri, Apr 16, 2004 at 22:12 -0400: > > I believe I have come up with a good solution to the kqueue woes in 5.X, and > > I'd like to get some feedback on work that so far is letting me (on > > uniprocessor, at least) run make -j8 buildworld, with USE_KQUEUE in make(1), > > with no ill effect :) The locking thus far is one global kqueue lock, and I > > firmly believe we should use MUTEX_PROFILING to determine if we should lock > > it down any further at this point. > > Ok, are you going to put together a 96 way SMP box with 90 different > webservers running to make sure this will scale that far?? Sure, a > global lock might work for a 2- or 4- way box, but are you prepared to > do the work necessary to make sure this is not a problem?? > > I thought the point of 5.x was to get things under their own locks > instead of moving to an spl based system (which is pretty much what > you've reimplemented)... NO ONE is going to put together a 96 way SMP box and try/want to run FreeBSD. FreeBSD is not going to scale there and kqueue will not be the only reason it won't, if that WOULD be a reason at all. That kind of thinking is how we get far too complicated locking schemes that hurt performance instead of improving it. How many instructions are run to put a knote on its queues? The 2- and 4- and maybe one day 8- (but it doesn't work now!) boxes will probably never have contention with a global lock with kqueue. What makes you think a subsystem lock is "bad" for kqueue? The scheduler has one, select()/poll() have one, semaphore, time, dev_t.... > > 1. The recursion has been removed from kqueue. This means kqueues cannot be > > added to other kqueues for EVFILT_READ -- yes, that ability has been > > around since r1.1 of kern_event.c, but it is utterly pointless and if you > > take a look at my previous patch, severely complicates many things. Of > > course, I'm sure someone will notice and complain, but there isn't any > > documentation that suggests you should kevent() another kqueue(). > > This is a bug as other people point out... Are you going to make it so > you can't select/poll on a kqueue too? Yes, and I'm going to gratuitously change around the kevent structure just to rename all the elements. .... IFF you in the future want to have more locking, like per-kqueue locks, you are going to be bitten IN THE ASS by this because the kqueue is the parent of a knote, not the other way around, and you can't lock both ways. It just don't work. You need to stop complaining about what has to be removed first to make kqueue not be totally broken unless you're coming up, now, with how to fix that. This is how the kernel gets so damn big and broken and so many things get reinvented all the time. People add features that are not well-thought-out and implementations nigh on impossible to modernify. You just can't do this shit. If you want to have anything other than a giant lock on kqueues, you would not be saying "WE CANNOT REMOVE THAT!" without saying how things have to be completely redesigned to take that into account. -- Brian Fundakowski Feldman \'[ FreeBSD ]''''''''''\ <> green@FreeBSD.org \ The Power to Serve! \ Opinions expressed are my own. \,,,,,,,,,,,,,,,,,,,,,,\
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200404172248.i3HMmiVI042942>