From owner-freebsd-current@FreeBSD.ORG Thu Apr 24 06:29:31 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 017231065675 for ; Thu, 24 Apr 2008 06:29:31 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [209.31.154.42]) by mx1.freebsd.org (Postfix) with ESMTP id E957B8FC26 for ; Thu, 24 Apr 2008 06:29:30 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [209.31.154.41]) by cyrus.watson.org (Postfix) with ESMTP id 23A3146C24; Thu, 24 Apr 2008 02:29:30 -0400 (EDT) Date: Thu, 24 Apr 2008 07:29:30 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Antony Mawer In-Reply-To: <480FB389.2030102@mawer.org> Message-ID: <20080424072456.I9282@fledge.watson.org> References: <8481.1208889581@critter.freebsd.dk> <480E3E66.3000303@samsco.org> <480E589C.8010108@delphij.net> <480EE8B2.2020907@higis.ru> <20080423154626.F64388@fledge.watson.org> <480FB389.2030102@mawer.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-current@freebsd.org, Dmitriy Kirhlarov Subject: Re: Http Accept filters (accf_http) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Apr 2008 06:29:31 -0000 On Thu, 24 Apr 2008, Antony Mawer wrote: > Robert Watson wrote: > ... >> I'm aware of a few problems relating to accept filters, and "fixing" them >> has been on my todo list for several years. Unfortunately, other things >> keep getting ahead of that in the todo list. One known issue is that >> accept filters aren't entirely happy with the new multi-processor locking >> world order. > > Does this mean that on a multi-core system, one is better avoiding accept > filters and accepting a small latency hit in return for better SMP > scalability/reduced lock contention? My intuition would have been to avoid it, except that I've had reports from some very high-end hosting providers (thousands of front-end systems) that it appears to work fine in practice. Sometimes it's hard to say what problems will be visible, and what won't. It's quite possible that since accept filters always run from the input path, they are always protected by &tcbinfo in 5.3-7.0, and as such the races aren't exercisable in practice, and they work just fine. If you are running with accept filters and *are* running into problems, I can try and make some time to diagnose the problem, since if a problem does exist, I would like to fix it. If tcbinfo is preventing it, we will need to fix them in 8.x, as we're eating away at that lock in order to improve input path parallelism. Robert N M Watson Computer Laboratory University of Cambridge