xfs
[Top] [All Lists]

Re: Review: Reduce in-core superblock lock contention near ENOSPC

To: David Chinner <dgc@xxxxxxx>
Subject: Re: Review: Reduce in-core superblock lock contention near ENOSPC
From: Klaus Strebel <klaus.strebel@xxxxxxx>
Date: Tue, 05 Dec 2006 12:46:46 +0100
Cc: Lachlan McIlroy <lachlan@xxxxxxx>, xfs-dev@xxxxxxx, xfs@xxxxxxxxxxx
In-reply-to: <20061203234928.GA37654165@melbourne.sgi.com>
References: <20061123044122.GU11034@melbourne.sgi.com> <456F1CFC.2060705@sgi.com> <20061130223810.GO37654165@melbourne.sgi.com> <457080EA.1010807@sgi.com> <20061203234928.GA37654165@melbourne.sgi.com>
Sender: xfs-bounce@xxxxxxxxxxx
User-agent: Thunderbird 3.0a1 (Windows/20061204)
David Chinner wrote:
On Fri, Dec 01, 2006 at 07:22:18PM +0000, Lachlan McIlroy wrote:
David Chinner wrote:
On Thu, Nov 30, 2006 at 06:03:40PM +0000, Lachlan McIlroy wrote:
I think the slow path code is somewhat clearer with a separate
mutex - it clearly documents the serialisation barrier that
the slow path uses and allows us to do slow path checks on the
per-cpu counters without needing the SB_LOCK.
It's certainly an improvement over the original code.

It also means that in future, we can slowly remove the need for
holding the SB_LOCK across the entire rebalance operation and only
use it when referencing the global superblock fields during
the rebalance.
Sounds good.

If the need arises, it also means we can move to a mutex per counter
so we can independently rebalance different types of counters at the
same time (which we can't do right now).
That seems so obvious - I'm surprised we can't do it now.

Well, the reason I didn't go down this path in the first place was that typically only one type of counter would need rebalancing at a time (e.g. free blocks or free inodes, but not both at the same time). I tested this out on revenue2 with simultaneous creates and deletes of small files but could not cause contention on the single global lock under these loads. i also tried parallel writes of large files with creates and deletes, but hte create/delete was slowed sufficiently by the parallel writes that it once again didn't cause an issue.

Hence it didn't seem to be an issue and a single lock simplified
the initial implementation. What I'm thinking now is that it may
become an issue with MDFS as acheivable create and delete rates
should be much higher on one of these filesystems and then it may
prove to be an issue.

Cheers,

Dave.

Hi guys,

just updated my CVS copy from oss.sgi.com ( the linux-2.6-xfs ) and tried to compile ... but your patch failes to compile if HAVE_PERCPU_SB is #ifndef'd :-(, the m_icsb_mutex is not in the struct see xfs_mount.h. Make oldconfig didn't show HAVE_PERCPU_SB as option for .config, looks like nobody tested on a single processor config ??

Ciao
Klaus

--
Mit freundlichen Grüssen / best regards

Klaus Strebel, Dipl.-Inform. (FH), mailto:klaus.strebel@xxxxxxx

/"\
\ /     ASCII RIBBON CAMPAIGN
 X        AGAINST HTML MAIL
/ \


<Prev in Thread] Current Thread [Next in Thread>