From owner-freebsd-hackers@FreeBSD.ORG Tue May 18 19:56:38 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9AB9416A4CE for ; Tue, 18 May 2004 19:56:38 -0700 (PDT) Received: from Princeton.EDU (postoffice02.Princeton.EDU [128.112.130.38]) by mx1.FreeBSD.org (Postfix) with ESMTP id 46E4C43D2F for ; Tue, 18 May 2004 19:56:38 -0700 (PDT) (envelope-from yruan@cs.princeton.edu) Received: from smtpserver1.Princeton.EDU (smtpserver1.Princeton.EDU [128.112.129.65]) by Princeton.EDU (8.12.9/8.12.9) with ESMTP id i4J2u7rq027706 for ; Tue, 18 May 2004 22:56:37 -0400 (EDT) Received: from cs.princeton.edu (targe.CS.Princeton.EDU [128.112.139.194]) (authenticated bits=0)i4J2u6aE003421 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Tue, 18 May 2004 22:56:06 -0400 (EDT) Message-ID: <40AACCA0.757478CF@cs.princeton.edu> Date: Tue, 18 May 2004 22:55:28 -0400 From: Yaoping Ruan X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: hackers@freebsd.org Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Vnode exclusive locking X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 May 2004 02:56:38 -0000 Hi, Could someone here give me some optimization advice/reference about vnode locking? Recently we find that vnode lookup locking has significant negative impact on I/O latency. We trace down to two places in the source code which initiated the locking: 1. the vn_lock( ) in lookup( ), kern/vfs_lookup.c, which locks the current directory vnode. I suppose it is released until the target leaf vnode is found. Does this lock need to be exclusive? 2. the two vget() calls in kern/vfs_cache.c. After looking at the source code changing logs, it seems that there's a "LOCKSHARED" option to solve the problem. But this option is not included until release 5.0 or 5.1. So my question is why it used EXCLUSIVE lock for lookup (which is a cache hit path)? And is there any other issues if using SHARED lock? Any explanation and points to references would be greatly appreciated. -Yaoping