linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Glauber Costa <glommer@parallels.com>
To: Dave Chinner <david@fromorbit.com>
Cc: Glauber Costa <glommer@openvz.org>,
	linux-mm@kvack.org, cgroups@vger.kernel.org,
	Andrew Morton <akpm@linux-foundation.org>,
	Greg Thelen <gthelen@google.com>,
	kamezawa.hiroyu@jp.fujitsu.com, Michal Hocko <mhocko@suse.cz>,
	Johannes Weiner <hannes@cmpxchg.org>,
	linux-fsdevel@vger.kernel.org, Dave Chinner <dchinner@redhat.com>
Subject: Re: [PATCH v6 12/31] fs: convert inode and dentry shrinking to be node aware
Date: Sat, 18 May 2013 02:54:23 +0400	[thread overview]
Message-ID: <5196B51F.5030508@parallels.com> (raw)
In-Reply-To: <51964381.8010406@parallels.com>

On 05/17/2013 06:49 PM, Glauber Costa wrote:
> On 05/17/2013 11:29 AM, Glauber Costa wrote:
>> Except that shrink_slab_node would also defer work, right?
>>
>>>> The only thing I don't like about this is the extra nodemask needed,
>>>> which, like the scan control, would have to sit on the stack.
>>>> Suggestions for avoiding that problem are welcome.. :)
>>>>
>> I will try to come up with a patch to do all this, and then we can
>> concretely discuss.
>> You are also of course welcome to do so as well =)
> 
> 
> All right.
> 
> I played a bit today with variations of this patch that will keep the
> deferred count per node. I will rebase the whole series ontop of it (the
> changes can get quite disruptive) and post. I want to believe that
> after this, all our regression problems will be gone (famous last words).
> 
> As I have told you, I wasn't seeing problems like you are, and
> speculated that this was due to the disk speeds. While this is true,
> the patch I came up with makes my workload actually a lot better.
> While my caches weren't being emptied, they were being slightly depleted
> and then slowly filled again. With my new patch, it is almost
> a straight line throughout the whole find run. There is a dent here and
> there eventually, but it recovers quickly. It takes some time as well
> for steady state to be reached, but once it is, we have all variables
> in the equation (dentries, inodes, etc) basically flat. So I guess it
> works, and I am confident that it will make your workload better.
> 
> My strategy is to modify the shrinker structure like this:
> 
> struct shrinker {
>         int (*shrink)(struct shrinker *, struct shrink_control *sc);
>         long (*count_objects)(struct shrinker *, struct shrink_control *sc);
>         long (*scan_objects)(struct shrinker *, struct shrink_control *sc);
> 
>         int seeks;      /* seeks to recreate an obj */
>         long batch;     /* reclaim batch size, 0 = default */
>         unsigned long flags;
> 
>         /* These are for internal use */
>         struct list_head list;
>         atomic_long_t *nr_deferred; /* objs pending delete, per node */
> 
>         /* nodes being currently shrunk, only makes sense for NUMA
> shrinkers */
>         nodemask_t *nodes_shrinking;
> 
> };
> 
> We need memory allocation now for nr_deferred and nodes_shrinking, but
> OTOH we use no stack, and can keep the size of this to be dynamically
> adjusted depending on whether or not your shrinker is NUMA aware.
> 
> Guess that is it. Expect news soon.
> 

Except of course that struct shrinker is obviously shared between runs,
and this won't cut.

Right now I am inclined to really just put this in the stack. The
alternative, if it becomes a problem, can be to extend the lru apis
to allow us to go for a single node. This way we only need to use 1
extra word in the stack.

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

  reply	other threads:[~2013-05-17 22:53 UTC|newest]

Thread overview: 63+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-05-12 18:13 [PATCH v6 00/31] kmemcg shrinkers Glauber Costa
2013-05-12 18:13 ` [PATCH v6 01/31] super: fix calculation of shrinkable objects for small numbers Glauber Costa
2013-05-12 18:13 ` [PATCH v6 02/31] dcache: convert dentry_stat.nr_unused to per-cpu counters Glauber Costa
2013-05-12 18:13 ` [PATCH v6 03/31] dentry: move to per-sb LRU locks Glauber Costa
2013-05-12 18:13 ` [PATCH v6 04/31] dcache: remove dentries from LRU before putting on dispose list Glauber Costa
2013-05-14  2:02   ` Dave Chinner
2013-05-14  5:46   ` [PATCH v7 " Dave Chinner
2013-05-14  7:10     ` Dave Chinner
2013-05-14 12:43     ` Glauber Costa
2013-05-14 20:32       ` Dave Chinner
2013-05-12 18:13 ` [PATCH v6 05/31] mm: new shrinker API Glauber Costa
2013-05-12 18:13 ` [PATCH v6 06/31] shrinker: convert superblock shrinkers to new API Glauber Costa
2013-05-12 18:13 ` [PATCH v6 07/31] list: add a new LRU list type Glauber Costa
2013-05-13  9:25   ` Mel Gorman
2013-05-12 18:13 ` [PATCH v6 08/31] inode: convert inode lru list to generic lru list code Glauber Costa
2013-05-12 18:13 ` [PATCH v6 09/31] dcache: convert to use new lru list infrastructure Glauber Costa
2013-05-14  6:59   ` Dave Chinner
2013-05-14  7:50     ` Glauber Costa
2013-05-14 14:01     ` Glauber Costa
2013-05-12 18:13 ` [PATCH v6 10/31] list_lru: per-node " Glauber Costa
2013-05-12 18:13 ` [PATCH v6 11/31] shrinker: add node awareness Glauber Costa
2013-05-12 18:13 ` [PATCH v6 12/31] fs: convert inode and dentry shrinking to be node aware Glauber Costa
2013-05-14  9:52   ` Dave Chinner
2013-05-15 15:27     ` Glauber Costa
2013-05-16  0:02       ` Dave Chinner
2013-05-16  8:03         ` Glauber Costa
2013-05-16 19:14         ` Glauber Costa
2013-05-17  0:51           ` Dave Chinner
2013-05-17  7:29             ` Glauber Costa
2013-05-17 14:49               ` Glauber Costa
2013-05-17 22:54                 ` Glauber Costa [this message]
2013-05-18  3:39                 ` Dave Chinner
2013-05-18  7:20                   ` Glauber Costa
2013-05-12 18:13 ` [PATCH v6 13/31] xfs: convert buftarg LRU to generic code Glauber Costa
2013-05-12 18:13 ` [PATCH v6 14/31] xfs: convert dquot cache lru to list_lru Glauber Costa
2013-05-12 18:13 ` [PATCH v6 15/31] fs: convert fs shrinkers to new scan/count API Glauber Costa
2013-05-13  6:12   ` Artem Bityutskiy
2013-05-13  7:28     ` Glauber Costa
2013-05-13  7:43       ` Artem Bityutskiy
2013-05-13 10:36   ` Jan Kara
2013-05-12 18:13 ` [PATCH v6 16/31] drivers: convert shrinkers to new count/scan API Glauber Costa
2013-05-12 18:13 ` [PATCH v6 17/31] i915: bail out earlier when shrinker cannot acquire mutex Glauber Costa
2013-05-12 18:13 ` [PATCH v6 18/31] shrinker: convert remaining shrinkers to count/scan API Glauber Costa
2013-05-12 18:13 ` [PATCH v6 19/31] hugepage: convert huge zero page shrinker to new shrinker API Glauber Costa
2013-05-12 18:13 ` [PATCH v6 20/31] shrinker: Kill old ->shrink API Glauber Costa
2013-05-12 18:13 ` [PATCH v6 21/31] vmscan: also shrink slab in memcg pressure Glauber Costa
2013-05-12 18:13 ` [PATCH v6 22/31] memcg,list_lru: duplicate LRUs upon kmemcg creation Glauber Costa
2013-05-12 18:13 ` [PATCH v6 23/31] lru: add an element to a memcg list Glauber Costa
2013-05-12 18:13 ` [PATCH v6 24/31] list_lru: per-memcg walks Glauber Costa
2013-05-12 18:13 ` [PATCH v6 25/31] memcg: per-memcg kmem shrinking Glauber Costa
2013-05-12 18:13 ` [PATCH v6 26/31] memcg: scan cache objects hierarchically Glauber Costa
2013-05-12 18:13 ` [PATCH v6 27/31] vmscan: take at least one pass with shrinkers Glauber Costa
2013-05-12 18:13 ` [PATCH v6 28/31] super: targeted memcg reclaim Glauber Costa
2013-05-12 18:13 ` [PATCH v6 29/31] memcg: move initialization to memcg creation Glauber Costa
2013-05-12 18:13 ` [PATCH v6 30/31] vmpressure: in-kernel notifications Glauber Costa
2013-05-12 18:13 ` [PATCH v6 31/31] memcg: reap dead memcgs upon global memory pressure Glauber Costa
2013-05-13  7:14 ` [PATCH v6 00/31] kmemcg shrinkers Dave Chinner
2013-05-13  7:21   ` Dave Chinner
2013-05-13  8:00   ` Glauber Costa
2013-05-14  1:48     ` Dave Chinner
2013-05-14  5:22       ` Dave Chinner
2013-05-14  5:45         ` Dave Chinner
2013-05-14  7:38         ` Glauber Costa

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=5196B51F.5030508@parallels.com \
    --to=glommer@parallels.com \
    --cc=akpm@linux-foundation.org \
    --cc=cgroups@vger.kernel.org \
    --cc=david@fromorbit.com \
    --cc=dchinner@redhat.com \
    --cc=glommer@openvz.org \
    --cc=gthelen@google.com \
    --cc=hannes@cmpxchg.org \
    --cc=kamezawa.hiroyu@jp.fujitsu.com \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=mhocko@suse.cz \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox