From: Glauber Costa <glommer@parallels.com>
To: Ying Han <yinghan@google.com>
Cc: Michal Hocko <mhocko@suse.cz>,
Johannes Weiner <hannes@cmpxchg.org>, Mel Gorman <mel@csn.ul.ie>,
KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>,
Rik van Riel <riel@redhat.com>, Greg Thelen <gthelen@google.com>,
Christoph Lameter <cl@linux.com>,
KOSAKI Motohiro <kosaki.motohiro@gmail.com>,
linux-mm@kvack.org
Subject: Re: [RFC PATCH 3/6] memcg: restructure shrink_slab to walk memcg hierarchy
Date: Fri, 17 Aug 2012 09:53:03 +0400 [thread overview]
Message-ID: <502DDC3F.70902@parallels.com> (raw)
In-Reply-To: <CALWz4iyp3H_v9k8ipPSYMijWcrNWvCGGNQ-mDH3N5qYeMPLCPg@mail.gmail.com>
On 08/17/2012 09:53 AM, Ying Han wrote:
>> > If the other shrinkers are not memcg aware, they will end up discarding
>> > random objects that may or may not have anything to do with the group
>> > under pressure, right?
> The main contributor of the accounted slabs and also reclaimable are
> vfs objects. Also we know dentry pins inode,
> so I wonder how bad the problem would be. Do you have specific example
> on which shrinker could cause the problem?
>
I don't have any specific shrinkers in mind, but as you said yourself:
the main contributors comes from the VFS. So as long as we shrink the
VFS objects - and those will be memcg aware, why bother with the others?
It seems to me that we're just risking breaking isolation for very
little gain.
--
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>
prev parent reply other threads:[~2012-08-17 5:56 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-08-16 20:53 [RFC PATCH 3/6] memcg: restructure shrink_slab to walk memcg hierarchy Ying Han
2012-08-17 5:38 ` Glauber Costa
2012-08-17 5:46 ` Ying Han
2012-08-17 5:45 ` Glauber Costa
2012-08-17 5:53 ` Ying Han
2012-08-17 5:53 ` Glauber Costa [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=502DDC3F.70902@parallels.com \
--to=glommer@parallels.com \
--cc=cl@linux.com \
--cc=gthelen@google.com \
--cc=hannes@cmpxchg.org \
--cc=kamezawa.hiroyu@jp.fujitsu.com \
--cc=kosaki.motohiro@gmail.com \
--cc=linux-mm@kvack.org \
--cc=mel@csn.ul.ie \
--cc=mhocko@suse.cz \
--cc=riel@redhat.com \
--cc=yinghan@google.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.