From owner-freebsd-arch@FreeBSD.ORG Sat Apr 17 15:14:44 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id ACBA716A4CE for ; Sat, 17 Apr 2004 15:14:44 -0700 (PDT) Received: from mail4.speakeasy.net (mail4.speakeasy.net [216.254.0.204]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7812543D1D for ; Sat, 17 Apr 2004 15:14:44 -0700 (PDT) (envelope-from jmg@hydrogen.funkthat.com) Received: (qmail 3172 invoked from network); 17 Apr 2004 22:14:44 -0000 Received: from dsl017-045-168.spk4.dsl.speakeasy.net (HELO hydrogen.funkthat.com) ([69.17.45.168]) (envelope-sender ) by mail4.speakeasy.net (qmail-ldap-1.03) with SMTP for ; 17 Apr 2004 22:14:44 -0000 Received: from hydrogen.funkthat.com (qnunef@localhost.funkthat.com [127.0.0.1])i3HMEgOE074631; Sat, 17 Apr 2004 15:14:43 -0700 (PDT) (envelope-from jmg@hydrogen.funkthat.com) Received: (from jmg@localhost) by hydrogen.funkthat.com (8.12.10/8.12.10/Submit) id i3HMEg7e074630; Sat, 17 Apr 2004 15:14:42 -0700 (PDT) Date: Sat, 17 Apr 2004 15:14:42 -0700 From: John-Mark Gurney To: Brian Fundakowski Feldman Message-ID: <20040417221442.GW567@funkthat.com> Mail-Followup-To: Brian Fundakowski Feldman , arch@freebsd.org References: <200404170212.i3H2Cg8n031749@green.homeunix.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200404170212.i3H2Cg8n031749@green.homeunix.org> User-Agent: Mutt/1.4.1i X-Operating-System: FreeBSD 4.2-RELEASE i386 X-PGP-Fingerprint: B7 EC EF F8 AE ED A7 31 96 7A 22 B3 D8 56 36 F4 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html cc: arch@freebsd.org Subject: Re: kqueue giant-locking (&kq_Giant, locking) X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: John-Mark Gurney List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Apr 2004 22:14:44 -0000 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)... > 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? -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not."