From owner-freebsd-arch@FreeBSD.ORG Sat May 22 23:59:30 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from green.homeunix.org (freefall.freebsd.org [216.136.204.21]) by hub.freebsd.org (Postfix) with ESMTP id A42FD16A4CE; Sat, 22 May 2004 23:59:30 -0700 (PDT) Received: from green.homeunix.org (green@localhost [127.0.0.1]) by green.homeunix.org (8.12.11/8.12.11) with ESMTP id i4N6xUEc059178; Sun, 23 May 2004 02:59:30 -0400 (EDT) (envelope-from green@green.homeunix.org) Received: (from green@localhost) by green.homeunix.org (8.12.11/8.12.11/Submit) id i4N6xTIH059177; Sun, 23 May 2004 02:59:29 -0400 (EDT) (envelope-from green) Date: Sun, 23 May 2004 02:59:28 -0400 From: Brian Feldman To: Peter Jeremy Message-ID: <20040523065928.GD51125@green.homeunix.org> References: <40AD2405.DC13B45C@freebsd.org> <20040521213208.GA87546@cirb503493.alcatel.com.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040521213208.GA87546@cirb503493.alcatel.com.au> User-Agent: Mutt/1.5.6i cc: Robert Watson cc: arch@freebsd.org cc: Andre Oppermann Subject: Re: Network Stack Locking X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 May 2004 06:59:31 -0000 On Sat, May 22, 2004 at 07:32:08AM +1000, Peter Jeremy wrote: > On Thu, 2004-May-20 23:32:53 +0200, Andre Oppermann wrote: > >Robert Watson wrote: > >... > >> Note that there are some serious issues with the current locking changes: > >Progress happens incrementally. Put in Green's kqueue locking, have > >that working correctly and make it perfect in a second step. > > I don't believe this is the correct approach at this time. Brian's > code removes functionality that people have stated that they _do_ use. > In theory, John-Mark's approach offers better performance without the > loss of functionality. Before implementing Brian's code, the Project > needs to decide which direction it should move in. *shrug* I added recursive kqueues because some people indicated that they actually had reason to use it. I still haven't added the NOTE_TRACK functionality because there is no known project in the entire world that uses it, so it has no chance of breaking anything at all for me by not having it. Anyway, I still want to see any alternative kqueue locking implementations. I haven't even seen a complete enough description of what the proposed change is supposed to look like to know whether it actually solves all of the issues that kqueue has now. If someone posts all the details and not just bits and pieces.... I don't know why I am the only person to have taken a shot at a complete implementation when the subsystem is so completely MP-broken already. -- Brian Fundakowski Feldman \'[ FreeBSD ]''''''''''\ <> green@FreeBSD.org \ The Power to Serve! \ Opinions expressed are my own. \,,,,,,,,,,,,,,,,,,,,,,\