Re: [PATCH v1 0/8] Deferred dput() and iput() -- reducing lock contention

From: Mike Waychison
Date: Tue Jan 20 2009 - 14:01:51 EST

Dave Chinner wrote:
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

[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.....

I'll dig through the archives and try to come up with a response later today.

Besides various workload testing,


I ran a couple different workloads, though I was looking for stability/correctness rather than performance. I ran iozone (ext2 + ext4/nojournal), dbench (ext2), tbench (ext2), specjbb, unixbench, kernbench as well as a couple internal benchmarks.
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at
Please read the FAQ at