From owner-cvs-all@FreeBSD.ORG Sun Mar 2 20:39:19 2008 Return-Path: Delivered-To: cvs-all@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9542F1065676; Sun, 2 Mar 2008 20:39:19 +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 57BD28FC17; Sun, 2 Mar 2008 20:39:19 +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 E59E046C23; Sun, 2 Mar 2008 15:39:18 -0500 (EST) Date: Sun, 2 Mar 2008 20:39:18 +0000 (GMT) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Yar Tikhiy In-Reply-To: Message-ID: <20080302203651.T31090@fledge.watson.org> References: <200803021856.m22IuEAx019455@repoman.freebsd.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: cvs-src@freebsd.org, src-committers@freebsd.org, cvs-all@freebsd.org Subject: Re: cvs commit: src/sys/fs/smbfs smbfs.h smbfs_node.c smbfs_vfsops.c X-BeenThere: cvs-all@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: CVS commit messages for the entire tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Mar 2008 20:39:19 -0000 On Sun, 2 Mar 2008, Yar Tikhiy wrote: > On Sun, Mar 2, 2008 at 9:56 PM, Robert Watson wrote: >> rwatson 2008-03-02 18:56:14 UTC >> >> FreeBSD src repository >> >> Modified files: >> sys/fs/smbfs smbfs.h smbfs_node.c smbfs_vfsops.c >> Log: >> Replace lockmgr lock protecting smbfs node hash table with sx lock. > > This commit message is a textbook example of how not to write commit > messages: It accurately re-tells what was obvious from the diff anyway but > provides no pointers to the background for the change. Sorry for my > bitching, but I just couldn't resist... :-) This change, the the similar change in nwfs, are part of a longer running effort to move towards using our SMPng locks rather than the less well-optimized and generally less pretty pre-SMPng primitives. I wouldn't expect any noticeable improvement in performance, and ideally no change in behavior, but it does reduce the number of unnecessary lockmgr consumers. In this context, my definition of "necessary" is where a consumer relies on specific semantics of lockmgr to function, such as LK_DRAIN, LK_UPGRADE, etc, which don't have comparable behavior with the newer primitives. Robert N M Watson Computer Laboratory University of Cambridge