From: Hillf Danton <dhillf@gmail.com>
To: Michal Hocko <mhocko@suse.cz>
Cc: linux-mm@kvack.org, Johannes Weiner <hannes@cmpxchg.org>,
KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>,
Hugh Dickins <hughd@google.com>,
Andrew Morton <akpm@linux-foundation.org>,
LKML <linux-kernel@vger.kernel.org>,
Balbir Singh <bsingharora@gmail.com>
Subject: Re: [PATCH] mm: memcg: remove checking reclaim order in soft limit reclaim
Date: Wed, 18 Jan 2012 22:01:57 +0800 [thread overview]
Message-ID: <CAJd=RBAs3_ic+0UbZ_Bn4tBp_t2-HuohcRrWD1d6M2oSYRNYmQ@mail.gmail.com> (raw)
In-Reply-To: <20120118134053.GD31112@tiehlicka.suse.cz>
On Wed, Jan 18, 2012 at 9:40 PM, Michal Hocko <mhocko@suse.cz> wrote:
> On Wed 18-01-12 20:30:41, Hillf Danton wrote:
>> On Tue, Jan 17, 2012 at 10:07 PM, Michal Hocko <mhocko@suse.cz> wrote:
>> > On Tue 17-01-12 21:29:52, Hillf Danton wrote:
>> >> On Tue, Jan 17, 2012 at 9:16 PM, Michal Hocko <mhocko@suse.cz> wrote:
>> >> > Hi,
>> >> >
>> >> > On Tue 17-01-12 20:47:59, Hillf Danton wrote:
>> >> >> If async order-O reclaim expected here, it is settled down when setting up scan
>> >> >> control, with scan priority hacked to be zero. Other than that, deny of reclaim
>> >> >> should be removed.
>> >> >
>> >> > Maybe I have misunderstood you but this is not right. The check is to
>> >> > protect from the _global_ reclaim with order > 0 when we prevent from
>> >> > memcg soft reclaim.
>> >> >
>> >> need to bear mm hog in this way?
>> >
>> > Could you be more specific? Are you trying to fix any particular
>> > problem?
>> >
>> My thought is simple, the outcome of softlimit reclaim depends little on the
>> value of reclaim order, zero or not, and only exceeding is reclaimed, so
>> selective response to swapd's request is incorrect.
>
> OK, got your point, finally. Let's add Balbir (the proposed patch can
> be found at https://lkml.org/lkml/2012/1/17/166) to the CC list because
> this seems to be a design decision.
>
> I always thought that this is because we want non-userspace (high order)
> mem pressure to be handled by the global reclaim only. And it makes some
> sense to me because it is little bit strange to reclaim for order-0
> while the request is for an higher order. I guess this might lead to an
> extensive and pointless reclaiming because we might end up with many
> free pages which cannot satisfy higher order allocation.
>
> On the other hand, it is true that the documentation says that the soft
> limit is considered when "the system detects memory contention or low
> memory" which doesn't say that the contention comes from memcg accounted
> memory.
>
> Anyway this changes the current behavior so it would better come with
> much better justification which shows that over reclaim doesn't happen
> and that we will not see higher latencies with higher order allocations.
>
As the function shows, the checked reclaim order is not used, but the
scan control is prepared with order(= 0), which is called async order-0
reclaim in my tern, then your worries on over reclaim and higher latencies
could be removed, I think 8-)
Thanks
Hillf
unsigned long mem_cgroup_shrink_node_zone(struct mem_cgroup *memcg,
gfp_t gfp_mask, bool noswap,
struct zone *zone,
unsigned long *nr_scanned)
{
struct scan_control sc = {
.nr_scanned = 0,
.nr_to_reclaim = SWAP_CLUSTER_MAX,
.may_writepage = !laptop_mode,
.may_unmap = 1,
.may_swap = !noswap,
.order = 0,
.target_mem_cgroup = memcg,
};
struct mem_cgroup_zone mz = {
.mem_cgroup = memcg,
.zone = zone,
};
sc.gfp_mask = (gfp_mask & GFP_RECLAIM_MASK) |
(GFP_HIGHUSER_MOVABLE & ~GFP_RECLAIM_MASK);
trace_mm_vmscan_memcg_softlimit_reclaim_begin(0,
sc.may_writepage,
sc.gfp_mask);
/*
* NOTE: Although we can get the priority field, using it
* here is not a good idea, since it limits the pages we can scan.
* if we don't reclaim here, the shrink_zone from balance_pgdat
* will pick up pages from other mem cgroup's as well. We hack
* the priority and make it zero.
*/
shrink_mem_cgroup_zone(0, &mz, &sc);
trace_mm_vmscan_memcg_softlimit_reclaim_end(sc.nr_reclaimed);
*nr_scanned = sc.nr_scanned;
return sc.nr_reclaimed;
}
next prev parent reply other threads:[~2012-01-18 14:02 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-01-17 12:47 [PATCH] mm: memcg: remove checking reclaim order in soft limit reclaim Hillf Danton
2012-01-17 13:16 ` Michal Hocko
2012-01-17 13:29 ` Hillf Danton
2012-01-17 14:07 ` Michal Hocko
2012-01-18 12:30 ` Hillf Danton
2012-01-18 13:40 ` Michal Hocko
2012-01-18 14:01 ` Hillf Danton [this message]
2012-01-18 15:13 ` Michal Hocko
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='CAJd=RBAs3_ic+0UbZ_Bn4tBp_t2-HuohcRrWD1d6M2oSYRNYmQ@mail.gmail.com' \
--to=dhillf@gmail.com \
--cc=akpm@linux-foundation.org \
--cc=bsingharora@gmail.com \
--cc=hannes@cmpxchg.org \
--cc=hughd@google.com \
--cc=kamezawa.hiroyu@jp.fujitsu.com \
--cc=linux-kernel@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;
as well as URLs for NNTP newsgroup(s).