Re: [PATCH v3] memcg: refactor mem_cgroup_resize_limit()

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



[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@xxxxxxxxxx>
> Acked-by: Vladimir Davydov <vdavydov.dev@xxxxxxxxx>

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@xxxxxxxx>
-- 
Michal Hocko
SUSE Labs

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



[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Bugtraq]     [Linux OMAP]     [Linux MIPS]     [eCos]     [Asterisk Internet PBX]     [Linux API]
  Powered by Linux