Received: by 2002:ac0:a5a6:0:0:0:0:0 with SMTP id m35-v6csp5491960imm; Wed, 12 Sep 2018 06:50:23 -0700 (PDT) X-Google-Smtp-Source: ANB0VdY1LAkpT7IoQGB5IV8O5f7e9mhgCWNBnJTrFy6ULGY2uWpQFD6mGHXgj3kMXvDL4k7PzV4q X-Received: by 2002:a63:e255:: with SMTP id y21-v6mr2459950pgj.160.1536760223361; Wed, 12 Sep 2018 06:50:23 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1536760223; cv=none; d=google.com; s=arc-20160816; b=0UtR/CLDOJsSkrBZkb4phrvDgK78TMvtUjc1p4KcrMorrxHHvypvv9GMQSVLWvxzSc KU3blfxLZ9yvluYiHFSOJqkO6owUjlSZSBiYZOslTyW5VdluKBChDLt2j2udIJggLXJu jpSLAQykf1xIFO3V93Zg191R3sxydhdT6DbE+b6aMTQjWo5abelr8SBuVQ9cpl0YWXm0 iy4DvD0WXMqzQwxEtHnDopC05RsCjU9DmD4LfJYbO0zI4W3K1kKAkAvp0/5owjZIbZju iyzlNYCFbUSYvAJGlrB08bbab3nc1as/nf9wQ8AA7dJQGImKDsLRrq9bm0OhZFDV/7aj x10g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date; bh=NZgeAQdDTvOen+JfJZeNVIHVHAUTg+Iv4pxgF2IqrnY=; b=IW6wnRg3wZoN52ESv9fJB8tfT+FGJKu6UKMpDO9BmLZgHHd5rjYHhAggAylRVgbslT kW1OWUVnRbWFUupGYFSkyqY2OK1sRjsfUA4NmtwnJ/O/ZBgRXznMHKGs5TOCmgjDc4Fc JJXWOWIyb44GlWc0jXij/ToNObXK1+5UbCu+oNisKSdxhIYY0JemG/JKUwWd8kAVau8y NgNPIFcC8+rBZu9uNVNKmz3loHihN/ovyrMnWBptW5N/L5qhTVMYPPPaZiB2oO3bfbBC kXsmj7OSo1+jAVTd61vzGnQze5qNBY4jZ0BbMbRyHCCwzS0hhoMm7ADaoL57oAMfKLs/ uGPQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id p3-v6si972962pld.329.2018.09.12.06.50.07; Wed, 12 Sep 2018 06:50:23 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727655AbeILSyi (ORCPT + 99 others); Wed, 12 Sep 2018 14:54:38 -0400 Received: from mx2.suse.de ([195.135.220.15]:38870 "EHLO mx1.suse.de" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1726798AbeILSyi (ORCPT ); Wed, 12 Sep 2018 14:54:38 -0400 X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay1.suse.de (unknown [195.135.220.254]) by mx1.suse.de (Postfix) with ESMTP id 5A081AF5B; Wed, 12 Sep 2018 13:50:00 +0000 (UTC) Date: Wed, 12 Sep 2018 15:49:59 +0200 From: Michal Hocko To: Li RongQing 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 Message-ID: <20180912134959.GK10951@dhcp22.suse.cz> References: <1536743960-19703-1-git-send-email-lirongqing@baidu.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1536743960-19703-1-git-send-email-lirongqing@baidu.com> User-Agent: Mutt/1.10.1 (2018-07-13) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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 > --- > 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