LKML Archive on
help / color / mirror / Atom feed
From: Bill Huey (hui) <>
To: Christoph Hellwig <>
Cc:,,,, Ingo Molnar <>,
	Peter Zijlstra <>,
	"Bill Huey (hui)" <>
Subject: Re: [PATCH] remove sb->s_files and file_list_lock usage in dquot.c
Date: Thu, 8 Feb 2007 23:14:04 -0800	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

On Thu, Feb 08, 2007 at 01:01:21AM -0800, Bill Huey wrote:
> Christoph,
> The i_mutex lock the inode structure is also a source of contention
> heavy when running a lot of parallel "find"s. I'm sure that folks
> would be open to hearing suggestions regarding how to fix that.


And while you're at it, you should also know that dcache_lock is next
in line to be nixed out of existence if possible.

i_mutex is a bitch and I'm not even going to think about how to get
rid of it since it's so widely used in many places (file systems aren't
my think as well). Maybe some more precise tracking of contention paths
would be useful to see if there's a pathological case creating a
cascade of contention events so that can be nixed, don't know.

About 1/10th of the lock stat events I've logged report that the owner
of the rtmutex is the "current" on a runqueue some where. An adaptive
lock would help with those contention events (spin for it while owner
is running for the mutex release) but really, the contention should be
avoided in the first place since they have a kind of (I think) polynomial
increase in contention time as you add more processors to the mix.

I have an adaptive lock implementation in my tree that eliminates
the contention between what looks like the IDE layer, work queues and
the anticipatory scheduler, but that's not a real problem unlike what
I've mentioned above. I can get you and others more specifics on the
problem if folks working on the lower layers want it.

Other than that the -rt patch does quite well with instrumenting all
sort of kernel behaviors that include contention and latency issues.

So I don't need to tell you how valuable the -rt patch is for these
issues since it's obvious, and I'm sure that you'll agree, that it's
been instrumental at discovering many problems with the stock kernel.


  reply	other threads:[~2007-02-09  7:14 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-02-06 13:23 Christoph Hellwig
2007-02-06 13:46 ` Jan Kara
2007-02-06 23:50 ` Andrew Morton
2007-02-07  7:22   ` Christoph Hellwig
2007-02-07 18:03     ` Jan Engelhardt
2007-02-07 19:06       ` Christoph Hellwig
2007-02-08 12:22         ` Jan Engelhardt
2007-02-07  8:35   ` Jan Kara
2007-02-08  9:01 ` Bill Huey
2007-02-09  7:14   ` Bill Huey [this message]
2007-02-09  7:23     ` Bill Huey

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \ \ \ \ \ \
    --subject='Re: [PATCH] remove sb->s_files and file_list_lock usage in dquot.c' \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).