From owner-freebsd-current@FreeBSD.ORG Mon Nov 26 22:31:50 2007 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 6164816A418; Mon, 26 Nov 2007 22:31:50 +0000 (UTC) (envelope-from bright@elvis.mu.org) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.freebsd.org (Postfix) with ESMTP id 4E62213C4D9; Mon, 26 Nov 2007 22:31:50 +0000 (UTC) (envelope-from bright@elvis.mu.org) Received: by elvis.mu.org (Postfix, from userid 1192) id 44EAB1A4D7E; Mon, 26 Nov 2007 14:12:26 -0800 (PST) Date: Mon, 26 Nov 2007 14:12:26 -0800 From: Alfred Perlstein To: Robert Watson Message-ID: <20071126221226.GJ71382@elvis.mu.org> References: <200711231232.04447.max@love2party.net> <20071126203514.X65286@fledge.watson.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20071126203514.X65286@fledge.watson.org> User-Agent: Mutt/1.4.2.3i Cc: Max Laier , freebsd-current@freebsd.org, freebsd-net@freebsd.org Subject: Re: Switch pfil(9) to rmlocks 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: Mon, 26 Nov 2007 22:31:50 -0000 * Robert Watson [071126 12:37] wrote: > > On Fri, 23 Nov 2007, Max Laier wrote: > > >attached is a diff to switch the pfil(9) subsystem to rmlocks, which are > >more suited for the task. I'd like some exposure before doing the switch, > >but I don't expect any fallout. This email is going through the patched > >pfil already - twice. > > FYI, since people are experimenting with rmlocks as a substitute for > rwlocks, I played with moving the global rwlock used to protect the name > space and linkage of UNIX domain sockets to be an rmlock. Kris didn't see > any measurable change in performance for his MySQL benchmarks, but I > figured I'd post the patches as they give a sense of what change impact > things like reader state management have on code. Attached below. I have > no current plans to commit these changes as they appear not to offer > benefit (either because the rwlock overhead was negigible compared to other > costs in the benchmark, or because the read/write blend was too scewed > towards writes -- I think probably the former rather than the latter). I would track the read/write lock mix to get an idea of what the ratio is. -Alfred