Re: [PATCH] disable demotion during memory reclamation

[Michal Hocko <mhocko@suse.com>]

On Tue 09-09-25 09:21:41, cuishiwei wrote:
> When a memory cgroup exceeds its memory limit, the system reclaims
> its cold memory.However, if /sys/kernel/mm/numa/demotion_enabled is
> set to 1, memory on fast memory nodes will also be demoted to slow 
> memory nodes.
> 
> This demotion contradicts the goal of reclaiming cold memory within
> the memcg.At this point, demoting cold memory from fast to slow nodes
> is pointless;it doesn't reduce the memcg's memory usage. Therefore, 
> we should set no_demotion when reclaiming memory in a memcg.

We have discussed this in the past and it is my recollection that we
have concluded that demotion is a part of proper aging and therefore it
should be done during the limit reclaim. Pro active reclaim through
memcg.memory_reclaim has a slightly different semantic (see
6b426d071419a).

I can see you have replied with more details to Andrew but in general it
is always better to describe your usecase and why the current behavior
is unexpected. Is the memory limit not being enforced? Do you see
unexpected memcg OOM situations? What is the actual problem?

> Signed-off-by: cuishiwei <cuishw@inspur.com>
> ---
>  mm/vmscan.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/mm/vmscan.c b/mm/vmscan.c
> index ca9e1cd3cd68..1edf618a3604 100644
> --- a/mm/vmscan.c
> +++ b/mm/vmscan.c
> @@ -6706,6 +6706,7 @@ unsigned long try_to_free_mem_cgroup_pages(struct mem_cgroup *memcg,
>  		.may_unmap = 1,
>  		.may_swap = !!(reclaim_options & MEMCG_RECLAIM_MAY_SWAP),
>  		.proactive = !!(reclaim_options & MEMCG_RECLAIM_PROACTIVE),
> +		.no_demotion = 1,
>  	};
>  	/*
>  	 * Traverse the ZONELIST_FALLBACK zonelist of the current node to put
> -- 
> 2.43.0
> 

-- 
Michal Hocko
SUSE Labs