Date: Wed, 22 Feb 2006 12:05:47 -0800
From: Andrew Morton <akpm@osdl.org>
To: Robin Holt <holt@sgi.com>
Cc: john@johnmccutchan.com, holt@sgi.com, linux-kernel@vger.kernel.org,
       rml@novell.com, arnd@arndb.de, hch@lst.de
Subject: Re: udevd is killing file write performance.
Message-Id: <20060222120547.2ae23a16.akpm@osdl.org>
In-Reply-To: <20060222175030.GB30556@lnx-holt.americas.sgi.com>
References: <20060222134250.GE20786@lnx-holt.americas.sgi.com>
	<1140626903.13461.5.camel@localhost.localdomain>
	<20060222175030.GB30556@lnx-holt.americas.sgi.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 915
Lines: 20

Robin Holt <holt@sgi.com> wrote:
>
> Let me reiterate, I know _VERY_ little about filesystems.  Can the
>  dentry->d_lock be changed to a read/write lock?

Well, it could, but I suspect that won't help - the hold times in there
will be very short so the problem is more likely acquisition frequency.

However it's a bit strange that this function is the bottleneck.  If their
workload is doing large numbers of reads or writes from large numbers of
processes against the same file then they should be hitting heavy
contention on other locks, such as i_sem and/or tree_lock and/or lru_lock
and others.

Can you tell us more about the kernel-visible behaviour of this app?
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/