Re: [PATCH] memcg: do not account memory used for cache creation

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

 



On Tue 04-06-13 18:10:59, Glauber Costa wrote:
> The memory we used to hold the memcg arrays is currently accounted to
> the current memcg.

Maybe I have missed a train but I thought that only some caches are
tracked and those have to be enabled explicitly by using __GFP_KMEMCG in
gfp flags.

But d79923fa "sl[au]b: allocate objects from memcg cache" seems to be
setting gfp unconditionally for large caches. The changelog doesn't
explain why, though? This is really confusing.

> But that creates a problem, because that memory can
> only be freed after the last user is gone. Our only way to know which is
> the last user, is to hook up to freeing time, but the fact that we still
> have some in flight kmallocs will prevent freeing to happen. I believe
> therefore to be just easier to account this memory as global overhead.

No internal allocations for memcg can be tracked otherwise we call for a
problem. How do we know that others are safe?

> Signed-off-by: Glauber Costa <glommer@xxxxxxxxxx>
> Cc: Johannes Weiner <hannes@xxxxxxxxxxx>
> Cc: Michal Hocko <mhocko@xxxxxxx>
> Cc: Kamezawa Hiroyuki <kamezawa.hiroyu@xxxxxxxxxxxxxx>
> 
> ---
> I noticed this while testing nuances of the shrinker patches. The
> caches would basically stay present forever, even if we managed to
> flush all of the actual memory being used. With this patch applied,
> they would go away all right.
> ---
>  mm/memcontrol.c | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/mm/memcontrol.c b/mm/memcontrol.c
> index 5d8b93a..aa1cbd4 100644
> --- a/mm/memcontrol.c
> +++ b/mm/memcontrol.c
> @@ -5642,7 +5642,9 @@ static int memcg_propagate_kmem(struct mem_cgroup *memcg)
>  	static_key_slow_inc(&memcg_kmem_enabled_key);
>  
>  	mutex_lock(&set_limit_mutex);
> +	memcg_stop_kmem_account();
>  	ret = memcg_update_cache_sizes(memcg);
> +	memcg_resume_kmem_account();
>  	mutex_unlock(&set_limit_mutex);
>  out:
>  	return ret;
> -- 
> 1.8.1.4
> 
> --
> 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>

-- 
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]     [Linux OMAP]     [Linux MIPS]     [ECOS]     [Asterisk Internet PBX]     [Linux API]