All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andrew Morton <akpm@linux-foundation.org>
To: Dave Chinner <david@fromorbit.com>
Cc: "Theodore Ts'o" <tytso@mit.edu>,
	Ext4 Developers List <linux-ext4@vger.kernel.org>,
	gnehzuil.liu@gmail.com, linux-fsdevel@vger.kernel.org
Subject: Re: [PATCH] fs: allow for fs-specific objects to be pruned as part of pruning inodes
Date: Thu, 24 Jan 2013 00:58:16 -0800	[thread overview]
Message-ID: <20130124005816.bce599de.akpm@linux-foundation.org> (raw)
In-Reply-To: <20130123133231.GS2498@dastard>

On Thu, 24 Jan 2013 00:32:31 +1100 Dave Chinner <david@fromorbit.com> wrote:

> Also, the superblock shrinker is designed around a direct 1:1:1
> dependency relationship between the superblock dentry, inode and "fs
> cache" objects. i.e. dentry pins inode pins fs cache object.  It is
> designed to keep a direct balance of the three caches by ensuring
> they get scanned in amounts directly proportional to the relative
> differences in their object counts.  That can't be done with
> separate shrinkers, hence the use of the superblock shrinker to
> define the dependent relationship between the caches.

I was staring at the code and at the 0e1fdafd9 changelog trying to work
out why prune_super() does its weird shrinker-in-a-shrinker thing.  And
failing.

IOW it needs a code comment, please.  Ideally one which explains *why*
"It is designed to keep a direct balance of the three caches...".  What
would go wrong if the fs were to just register its own shrinker in the
expected manner?


  parent reply	other threads:[~2013-01-24  8:57 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-01-11 10:53 [PATCH 0/7 v2] ext4: extent status tree (step2) Zheng Liu
2013-01-11 10:53 ` [PATCH 1/7 v2] ext4: refine extent status tree Zheng Liu
2013-01-23  4:20   ` Theodore Ts'o
2013-01-11 10:53 ` [PATCH 2/7 v2] ext4: remove EXT4_MAP_FROM_CLUSTER flag Zheng Liu
2013-01-11 10:53 ` [PATCH 3/7 v2] ext4: add physical block and status member into extent status tree Zheng Liu
2013-01-17  4:42   ` Theodore Ts'o
2013-01-18  9:49     ` Zheng Liu
2013-01-11 10:53 ` [PATCH 4/7 v2] ext4: adjust interfaces of " Zheng Liu
2013-01-11 10:53 ` [PATCH 5/7 v2] ext4: track all extent status in " Zheng Liu
2013-01-23  4:31   ` Theodore Ts'o
2013-01-11 10:53 ` [PATCH 6/7 v2] ext4: lookup block mapping " Zheng Liu
2013-01-18  4:00   ` Theodore Ts'o
2013-01-18  9:52     ` Zheng Liu
2013-01-11 10:53 ` [PATCH 7/7 v2] ext4: reclaim extents from " Zheng Liu
2013-01-18  5:19   ` Theodore Ts'o
2013-01-18  5:39     ` Theodore Ts'o
2013-01-21  7:24       ` Zheng Liu
2013-01-21 15:00         ` Theodore Ts'o
2013-01-21 17:09           ` Zheng Liu
2013-01-23  6:06             ` [PATCH] fs: allow for fs-specific objects to be pruned as part of pruning inodes Theodore Ts'o
2013-01-23 10:52               ` Jan Kara
2013-01-23 13:06               ` Carlos Maiolino
2013-01-23 13:32               ` Dave Chinner
2013-01-23 16:34                 ` Theodore Ts'o
2013-01-23 23:35                   ` Dave Chinner
2013-01-24  8:58                 ` Andrew Morton [this message]
2013-01-24 20:03                   ` Dave Chinner
2013-01-21 14:43       ` [PATCH 7/7 v2] ext4: reclaim extents from extent status tree Jan Kara
2013-01-21 15:12         ` Zheng Liu

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=20130124005816.bce599de.akpm@linux-foundation.org \
    --to=akpm@linux-foundation.org \
    --cc=david@fromorbit.com \
    --cc=gnehzuil.liu@gmail.com \
    --cc=linux-ext4@vger.kernel.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=tytso@mit.edu \
    /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.