All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mike Waychison <Michael.Waychison@Sun.COM>
To: William Lee Irwin III <wli@holomorphy.com>
Cc: Linux kernel <linux-kernel@vger.kernel.org>,
	viro@parcelfarce.linux.theplanet.co.uk
Subject: Re: [patch] Per-sb s_all_inodes list
Date: Mon, 10 Jan 2005 21:08:01 -0500	[thread overview]
Message-ID: <41E33501.1050506@sun.com> (raw)
In-Reply-To: <20050111012311.GD2696@holomorphy.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

William Lee Irwin III wrote:
> On Mon, Jan 10, 2005 at 04:19:24PM -0500, Mike Waychison wrote:
> 
>>Releasing a super_block requires walking all inodes for the given
>>superblock and releasing them. Currently, inodes are found on one of
>>four lists:
> 
> [...]
> 
>>The second list, inode_unused can potentially be quite large.
>>Unfortunately, it cannot be made per-sb as it is the global LRU list
>>used for inode cache reduction under memory pressure.
>>When unmounting a single filesystem, profiling shows dramatic time spent
>>walking inode_unused.  This because very noticeble when one is
>>unmounting a decently sized tree of filesystems.
>>The proposed solution is to create a new list per-sb, that contains all
>>inodes allocated.  It is maintained under the inode_lock for the sake of
>>simplicity, but this may prove unneccesary, and may be better done with
>>another global or per-sb lock.
> 
> 
> I thought this was a good idea a number of months ago myself when I saw
> a patch for 2.4.x implementing this from Kirill Korotaev, so I ported
> that code to 2.6.x and it got merged in -mm then. That patch was merged
> into Linus' bk shortly after 2.6.10. Could you check Linus' bk to see
> if what made it there resolves the issue as well as your own?
> 

Excellent.  I eyeballed the patch on bkbits.net and it does exactly what
I posted.

Thanks,

- --
Mike Waychison
Sun Microsystems, Inc.
1 (650) 352-5299 voice
1 (416) 202-8336 voice

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
NOTICE:  The opinions expressed in this email are held by me,
and may not represent the views of Sun Microsystems, Inc.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFB4zUBdQs4kOxk3/MRAhaKAJwJDvFtnb57DkMpWuEB1C8ePZItFwCfSLrm
IKROVg53ElpF8V8PQRRB7vQ=
=AjvL
-----END PGP SIGNATURE-----

      reply	other threads:[~2005-01-11  2:15 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-01-10 21:19 [patch] Per-sb s_all_inodes list Mike Waychison
2005-01-11  1:23 ` William Lee Irwin III
2005-01-11  2:08   ` Mike Waychison [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=41E33501.1050506@sun.com \
    --to=michael.waychison@sun.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=viro@parcelfarce.linux.theplanet.co.uk \
    --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.