[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20170613113545.GH10819@dhcp22.suse.cz>
Date: Tue, 13 Jun 2017 13:35:45 +0200
From: Michal Hocko <mhocko@...nel.org>
To: Yu Zhao <yuzhao@...gle.com>
Cc: Johannes Weiner <hannes@...xchg.org>,
Vladimir Davydov <vdavydov.dev@...il.com>,
cgroups@...r.kernel.org, linux-mm@...ck.org,
linux-kernel@...r.kernel.org, n.borisov.lkml@...il.com
Subject: Re: [PATCH v3] memcg: refactor mem_cgroup_resize_limit()
[Sorry for a late reponse]
On Sun 04-06-17 14:18:07, Yu Zhao wrote:
> mem_cgroup_resize_limit() and mem_cgroup_resize_memsw_limit() have
> identical logics. Refactor code so we don't need to keep two pieces
> of code that does same thing.
>
> Signed-off-by: Yu Zhao <yuzhao@...gle.com>
> Acked-by: Vladimir Davydov <vdavydov.dev@...il.com>
It is nice to see removal of the code duplication. I have one comment
though
[...]
> @@ -2498,22 +2449,24 @@ static int mem_cgroup_resize_memsw_limit(struct mem_cgroup *memcg,
> }
>
> mutex_lock(&memcg_limit_mutex);
> - if (limit < memcg->memory.limit) {
> + inverted = memsw ? limit < memcg->memory.limit :
> + limit > memcg->memsw.limit;
> + if (inverted) {
> mutex_unlock(&memcg_limit_mutex);
> ret = -EINVAL;
> break;
> }
This is just too ugly and hard to understand. inverted just doesn't give
you a good clue what is going on. What do you think about something like
/*
* Make sure that the new limit (memsw or hard limit) doesn't
* break our basic invariant that memory.limit <= memsw.limit
*/
limits_invariant = memsw ? limit >= memcg->memory.limit :
limit <= mmecg->memsw.limit;
if (!limits_invariant) {
mutex_unlock(&memcg_limit_mutex);
ret = -EINVAL;
break;
}
with that feel free to add
Acked-by: Michal Hocko <mhocko@...e.com>
--
Michal Hocko
SUSE Labs
Powered by blists - more mailing lists