All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andrew Morton <akpm@osdl.org>
To: Robin Holt <holt@sgi.com>
Cc: holt@sgi.com, linux-kernel@vger.kernel.org, dev@sw.ru,
	wli@holomorphy.com, steiner@sgi.com, sandeen@sgi.com
Subject: Re: 21 million inodes is causing severe pauses.
Date: Tue, 16 Nov 2004 11:15:32 -0800	[thread overview]
Message-ID: <20041116111532.3202e4e2.akpm@osdl.org> (raw)
In-Reply-To: <20041116163224.GB5594@lnx-holt.americas.sgi.com>

Robin Holt <holt@sgi.com> wrote:
>
>  On Mon, Nov 15, 2004 at 02:57:14PM -0800, Andrew Morton wrote:
>  > Robin Holt <holt@sgi.com> wrote:
>  > >
>  > > One significant problem we are running into is autofs trying to umount the
>  > > file systems.  This results in the umount grabbing the BKL and inode_lock,
>  > > holding it while it scans through the inode_list and others looking for
>  > > inodes used by this super block and attempting to free them.
>  > 
>  > You'll need invalidate_inodes-speedup.patch and
>  > break-latency-in-invalidate_list.patch (or an equivalent).
> 
>  With these patches and a new test where I periodically put on mild
>  but diminishing memory pressure, I have been able to get the number
>  of inodes up to 31 Million.  I would really like to find a way to
>  reduce limit the number of inodes or am I seeing a problem where
>  none exists?  After putting on constant mild memory pressure, I have
>  seen then number of inodes stabilize at 17-18 Million.

There shouldn't be anything wrong with that per-se.  You have a big system,
and a workload which touches a lot of inodes.  It would be best to fix up
the lock hold times rather than reducing the cached inode count because the
lock hold times are sucky.

That being said, you may get some joy by greatly increasing
/proc/sys/vm/vfs_cache_pressure. Try 10000.


      reply	other threads:[~2004-11-16 19:18 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-11-15 19:55 21 million inodes is causing severe pauses Robin Holt
2004-11-15 20:35 ` Norbert van Nobelen
2004-11-15 20:51   ` Robin Holt
2004-11-15 20:57   ` linux-os
2004-11-15 21:31     ` Robin Holt
2004-11-15 22:57 ` Andrew Morton
2004-11-16 16:28   ` Robin Holt
2004-11-16 19:13     ` Andrew Morton
2004-11-16 19:48       ` Robin Holt
2004-11-17  0:33         ` Andrew Morton
2004-11-17  0:54           ` Robin Holt
2004-11-17  1:05             ` Andrew Morton
2004-11-16 16:32   ` Robin Holt
2004-11-16 19:15     ` Andrew Morton [this message]

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=20041116111532.3202e4e2.akpm@osdl.org \
    --to=akpm@osdl.org \
    --cc=dev@sw.ru \
    --cc=holt@sgi.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=sandeen@sgi.com \
    --cc=steiner@sgi.com \
    --cc=wli@holomorphy.com \
    /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.