All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andrew Morton <akpm@digeo.com>
To: Matthew Wilcox <willy@debian.org>
Cc: linux-fsdevel@vger.kernel.org, viro@math.psu.edu
Subject: Re: inode rwlock instead of semaphore
Date: Sun, 2 Feb 2003 14:32:14 -0800	[thread overview]
Message-ID: <20030202143214.72ae2fa0.akpm@digeo.com> (raw)
In-Reply-To: <20030202174215.G21040@parcelfarce.linux.theplanet.co.uk>

Matthew Wilcox <willy@debian.org> wrote:
>
> On Sun, Feb 02, 2003 at 10:01:55AM -0700, Andreas Dilger wrote:
> > I'm wondering why we use a semaphore to lock directories on lookups instead
> > of a rwlock?  This would allow parallel lookups on directory entries instead
> > of single threading.  We have a need for directories with millions of files
> > in them, and being able to start parallel lookups would be a big performance
> > boost I think.
> 
> You mean a rwsem, not a rwlock, I assume?  How about starvation issues?
> 

Well...  things like starvation we could presumably fix with a new lock type
or whatever.

But Andreas is correct - holding i_sem on a directory while the holder is
performing synchronous I/O is a very serious scalability problem.

I hit it (badly) against /tmp: one process was unlinking a file in /tmp (and
hence waiting on underway writeback in truncate).  This prevents everything in
the machine from creating new files in /tmp until that I/O completes.

I fixed that specific problem by running the actual truncate outside i_sem in
sys_unlink().  But surely there will be other such problems.  sync and
dirsync mounts come to mind, as well as huge directories.

  reply	other threads:[~2003-02-02 22:32 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-02-02 17:01 inode rwlock instead of semaphore Andreas Dilger
2003-02-02 17:42 ` Matthew Wilcox
2003-02-02 22:32   ` Andrew Morton [this message]
2003-02-03 13:13 ` Jan Hudec
2003-02-03 17:47   ` Andreas Dilger

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:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

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

  git send-email \
    --in-reply-to=20030202143214.72ae2fa0.akpm@digeo.com \
    --to=akpm@digeo.com \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=viro@math.psu.edu \
    --cc=willy@debian.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.