From mboxrd@z Thu Jan 1 00:00:00 1970 From: Dave Chinner Subject: Re: [PATCH v1 0/8] Deferred dput() and iput() -- reducing lock contention Date: Sat, 17 Jan 2009 19:12:10 +1100 Message-ID: <20090117081210.GL8071@disturbed> References: <20090117022936.20425.43248.stgit@crlf.corp.google.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org To: Mike Waychison Return-path: Received: from ipmail04.adl2.internode.on.net ([203.16.214.57]:30857 "EHLO ipmail04.adl2.internode.on.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754050AbZAQIMP (ORCPT ); Sat, 17 Jan 2009 03:12:15 -0500 Content-Disposition: inline In-Reply-To: <20090117022936.20425.43248.stgit@crlf.corp.google.com> Sender: linux-fsdevel-owner@vger.kernel.org List-ID: On Fri, Jan 16, 2009 at 06:29:36PM -0800, Mike Waychison wrote: > We've noticed that at times it can become very easy to have a system begin to > livelock on dcache_lock/inode_lock (specifically in atomic_dec_and_lock()) when > a lot of dentries are getting finalized at the same time (massive delete and > large fdtable destructions are two paths I've seen cause problems). > > This patchset is an attempt to try and reduce the locking overheads associated > with final dput() and final iput(). This is done by batching dentries and > inodes into per-process queues and processing them in 'parallel' to consolidate > some of the locking. Hmmmm. This deferring of dput/iput will have the same class of effects on filesystems as the recent reverted changes to make generic_delete_inode() an asynchronous process. That is, it temporally separates the transaction for namespace deletion (i.e. unlink) from the transaction that completes the inode deletion that occurs, typically, during ->clear_inode. See the recent thread titled: [PATCH] async: Don't call async_synchronize_full_special() while holding sb_lock For more details. I suspect that change is likely to cause worse problems than the async changes in that it doesn't have a cap on the number of deferred operations..... > Besides various workload testing, Details? Cheers, Dave. -- Dave Chinner david@fromorbit.com