linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Michal Hocko <mhocko@kernel.org>
To: Li RongQing <lirongqing@baidu.com>
Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org,
	hannes@cmpxchg.org, vdavydov.dev@gmail.com
Subject: Re: [PATCH] memcg: remove congestion wait when force empty
Date: Wed, 12 Sep 2018 15:49:59 +0200	[thread overview]
Message-ID: <20180912134959.GK10951@dhcp22.suse.cz> (raw)
In-Reply-To: <1536743960-19703-1-git-send-email-lirongqing@baidu.com>

On Wed 12-09-18 17:19:20, Li RongQing wrote:
> memory.force_empty is used to empty a memory cgoup memory before
> rmdir it, avoid to charge those memory into parent cgroup

We do not reparent LRU pages on the memcg removal. We just keep
those pages around and reclaim them on the memory pressure. So the above
is not true anymore. You can use force_empty to release those pages
earlier though.

> when try_to_free_mem_cgroup_pages returns 0, guess there maybe be
> lots of writeback, so wait. but the waiting and sleep will called
> in shrink_inactive_list, based on numbers of isolated page, so
> remove this wait to reduce unnecessary delay

Have you ever seen this congestion_wait to be actually harmful?
You are right that the reclaim path already does sleep and we even wait
for pages under writeback for memcg v1. But there might be other reasons
why no pages are reclaimable at the moment and this congestion_wait is
meant to sleep for a while before retrying and running out of retries
too early.

That being said, the current code is not really great but could you
describe the actual problem you are seeing? 

> Signed-off-by: Li RongQing <lirongqing@baidu.com>
> ---
>  mm/memcontrol.c | 6 +-----
>  1 file changed, 1 insertion(+), 5 deletions(-)
> 
> diff --git a/mm/memcontrol.c b/mm/memcontrol.c
> index 4ead5a4817de..35bd43eaa97e 100644
> --- a/mm/memcontrol.c
> +++ b/mm/memcontrol.c
> @@ -2897,12 +2897,8 @@ static int mem_cgroup_force_empty(struct mem_cgroup *memcg)
>  
>  		progress = try_to_free_mem_cgroup_pages(memcg, 1,
>  							GFP_KERNEL, true);
> -		if (!progress) {
> +		if (!progress)
>  			nr_retries--;
> -			/* maybe some writeback is necessary */
> -			congestion_wait(BLK_RW_ASYNC, HZ/10);
> -		}
> -
>  	}
>  
>  	return 0;
> -- 
> 2.16.2

-- 
Michal Hocko
SUSE Labs

      reply	other threads:[~2018-09-12 13:50 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-09-12  9:19 Li RongQing
2018-09-12 13:49 ` Michal Hocko [this message]

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=20180912134959.GK10951@dhcp22.suse.cz \
    --to=mhocko@kernel.org \
    --cc=hannes@cmpxchg.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=lirongqing@baidu.com \
    --cc=vdavydov.dev@gmail.com \
    /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