From: Johannes Weiner <hannes@cmpxchg.org>
To: Michal Hocko <mhocko@suse.cz>
Cc: Andrew Morton <akpm@linux-foundation.org>,
Tejun Heo <tj@kernel.org>,
linux-mm@kvack.org, cgroups@vger.kernel.org,
linux-kernel@vger.kernel.org
Subject: Re: [patch 2/4] mm: memcontrol: add memory.current and memory.high to default hierarchy
Date: Thu, 7 Aug 2014 11:47:10 -0400 [thread overview]
Message-ID: <20140807154710.GE14734@cmpxchg.org> (raw)
In-Reply-To: <20140807133614.GC12730@dhcp22.suse.cz>
On Thu, Aug 07, 2014 at 03:36:14PM +0200, Michal Hocko wrote:
> On Mon 04-08-14 17:14:55, Johannes Weiner wrote:
> [...]
> > @@ -132,6 +137,19 @@ u64 res_counter_uncharge(struct res_counter *counter, unsigned long val);
> > u64 res_counter_uncharge_until(struct res_counter *counter,
> > struct res_counter *top,
> > unsigned long val);
> > +
> > +static inline unsigned long long res_counter_high(struct res_counter *cnt)
>
> soft limit used res_counter_soft_limit_excess which has quite a long
> name but at least those two should be consistent.
That name is horrible and a result from "soft_limit" being completely
nondescriptive. I really see no point in trying to be consistent with
this stuff that we are trying hard to delete.
> > @@ -2621,6 +2621,20 @@ bypass:
> > done_restock:
> > if (batch > nr_pages)
> > refill_stock(memcg, batch - nr_pages);
> > +
> > + res = &memcg->res;
> > + while (res) {
> > + unsigned long long high = res_counter_high(res);
> > +
> > + if (high) {
> > + unsigned long high_pages = high >> PAGE_SHIFT;
> > + struct mem_cgroup *memcg;
> > +
> > + memcg = mem_cgroup_from_res_counter(res, res);
> > + mem_cgroup_reclaim(memcg, high_pages, gfp_mask, 0);
> > + }
> > + res = res->parent;
> > + }
> > done:
> > return ret;
> > }
>
> Why haven't you followed what we do for hard limit here?
I did.
> In my implementation I have the following:
>
> diff --git a/mm/memcontrol.c b/mm/memcontrol.c
> index a37465fcd8ae..6a797c740ea5 100644
> --- a/mm/memcontrol.c
> +++ b/mm/memcontrol.c
> @@ -2529,6 +2529,21 @@ static int memcg_cpu_hotplug_callback(struct notifier_block *nb,
> return NOTIFY_OK;
> }
>
> +static bool high_limit_excess(struct mem_cgroup *memcg,
> + struct mem_cgroup **memcg_over_limit)
> +{
> + struct mem_cgroup *parent = memcg;
> +
> + do {
> + if (res_counter_limit_excess(&parent->res, RES_HIGH_LIMIT)) {
> + *memcg_over_limit = parent;
> + return true;
> + }
> + } while ((parent = parent_mem_cgroup(parent)));
> +
> + return false;
> +}
> +
> static int try_charge(struct mem_cgroup *memcg, gfp_t gfp_mask,
> unsigned int nr_pages)
> {
> @@ -2623,6 +2638,10 @@ bypass:
> goto retry;
>
> done_restock:
> + /* Throttle charger a bit if it is above high limit. */
> + if (high_limit_excess(memcg, &mem_over_limit))
> + mem_cgroup_reclaim(mem_over_limit, gfp_mask, flags);
This is not what the hard limit does.
The hard limit, by its nature, can only be exceeded at one level at a
time, so we try to charge, check the closest limit that was hit,
reclaim, then retry. This means we are reclaiming up the hierarchy to
enforce the hard limit on each level.
I do the same here: reclaim up the hierarchy to enforce the high limit
on each level.
Your proposal only reclaims the closest offender, leaving higher
hierarchy levels in excess.
next prev parent reply other threads:[~2014-08-07 15:47 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-08-04 21:14 [patch 0/4] mm: memcontrol: populate unified hierarchy interface Johannes Weiner
2014-08-04 21:14 ` [patch 1/4] mm: memcontrol: reduce reclaim invocations for higher order requests Johannes Weiner
2014-08-07 13:08 ` Michal Hocko
2014-08-07 15:31 ` Johannes Weiner
2014-08-07 16:10 ` Greg Thelen
2014-08-08 12:47 ` Michal Hocko
2014-08-08 12:32 ` Michal Hocko
2014-08-08 13:26 ` Johannes Weiner
2014-08-11 7:49 ` Michal Hocko
2014-08-13 14:59 ` Michal Hocko
2014-08-13 20:41 ` Johannes Weiner
2014-08-14 16:12 ` Michal Hocko
2014-08-04 21:14 ` [patch 2/4] mm: memcontrol: add memory.current and memory.high to default hierarchy Johannes Weiner
2014-08-07 13:36 ` Michal Hocko
2014-08-07 13:39 ` Michal Hocko
2014-08-07 15:47 ` Johannes Weiner [this message]
2014-08-04 21:14 ` [patch 3/4] mm: memcontrol: add memory.max " Johannes Weiner
2014-08-04 21:14 ` [patch 4/4] mm: memcontrol: add memory.vmstat " Johannes Weiner
2014-08-05 12:40 ` [patch 0/4] mm: memcontrol: populate unified hierarchy interface Michal Hocko
2014-08-05 13:53 ` Johannes Weiner
2014-08-05 15:27 ` Michal Hocko
2014-08-07 14:21 ` Johannes Weiner
-- strict thread matches above, loose matches on Subject: below --
2014-08-08 21:38 [patch 0/4] mm: memcontrol: populate unified hierarchy interface v2 Johannes Weiner
2014-08-08 21:38 ` [patch 2/4] mm: memcontrol: add memory.current and memory.high to default hierarchy Johannes Weiner
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=20140807154710.GE14734@cmpxchg.org \
--to=hannes@cmpxchg.org \
--cc=akpm@linux-foundation.org \
--cc=cgroups@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mhocko@suse.cz \
--cc=tj@kernel.org \
/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