From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andrew Morton Subject: Re: inode rwlock instead of semaphore Date: Sun, 2 Feb 2003 14:32:14 -0800 Sender: linux-fsdevel-owner@vger.kernel.org Message-ID: <20030202143214.72ae2fa0.akpm@digeo.com> References: <20030202100155.A18636@schatzie.adilger.int> <20030202174215.G21040@parcelfarce.linux.theplanet.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: linux-fsdevel@vger.kernel.org, viro@math.psu.edu Return-path: Received: from digeo-nav01.digeo.com (digeo-nav01.digeo.com [192.168.1.233]) by packet.digeo.com (8.9.3+Sun/8.9.3) with SMTP id OAA17637 for ; Sun, 2 Feb 2003 14:32:02 -0800 (PST) To: Matthew Wilcox In-Reply-To: <20030202174215.G21040@parcelfarce.linux.theplanet.co.uk> List-Id: linux-fsdevel.vger.kernel.org Matthew Wilcox wrote: > > On Sun, Feb 02, 2003 at 10:01:55AM -0700, Andreas Dilger wrote: > > I'm wondering why we use a semaphore to lock directories on lookups instead > > of a rwlock? This would allow parallel lookups on directory entries instead > > of single threading. We have a need for directories with millions of files > > in them, and being able to start parallel lookups would be a big performance > > boost I think. > > You mean a rwsem, not a rwlock, I assume? How about starvation issues? > Well... things like starvation we could presumably fix with a new lock type or whatever. But Andreas is correct - holding i_sem on a directory while the holder is performing synchronous I/O is a very serious scalability problem. I hit it (badly) against /tmp: one process was unlinking a file in /tmp (and hence waiting on underway writeback in truncate). This prevents everything in the machine from creating new files in /tmp until that I/O completes. I fixed that specific problem by running the actual truncate outside i_sem in sys_unlink(). But surely there will be other such problems. sync and dirsync mounts come to mind, as well as huge directories.