From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-4.0 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id F1848C433DF for ; Mon, 3 Aug 2020 14:34:49 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id B22E7206D4 for ; Mon, 3 Aug 2020 14:34:49 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org B22E7206D4 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=suse.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 2FBB48D0101; Mon, 3 Aug 2020 10:34:50 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 2AC7F8D0081; Mon, 3 Aug 2020 10:34:50 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 1C2218D0101; Mon, 3 Aug 2020 10:34:50 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0069.hostedemail.com [216.40.44.69]) by kanga.kvack.org (Postfix) with ESMTP id 058268D0081 for ; Mon, 3 Aug 2020 10:34:50 -0400 (EDT) Received: from smtpin16.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay03.hostedemail.com (Postfix) with ESMTP id A7F328248047 for ; Mon, 3 Aug 2020 14:34:49 +0000 (UTC) X-FDA: 77109503898.16.table94_5804c4b26f9e Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin16.hostedemail.com (Postfix) with ESMTP id 53C9C100E692B for ; Mon, 3 Aug 2020 14:34:49 +0000 (UTC) X-HE-Tag: table94_5804c4b26f9e X-Filterd-Recvd-Size: 5049 Received: from mx2.suse.de (mx2.suse.de [195.135.220.15]) by imf07.hostedemail.com (Postfix) with ESMTP for ; Mon, 3 Aug 2020 14:34:48 +0000 (UTC) X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.221.27]) by mx2.suse.de (Postfix) with ESMTP id A89C2ABCE; Mon, 3 Aug 2020 14:35:02 +0000 (UTC) Date: Mon, 3 Aug 2020 16:34:46 +0200 From: Michal Hocko To: Yafang Shao Cc: longman@redhat.com, Johannes Weiner , Andrew Morton , Linux MM Subject: Re: [PATCH] mm, memcg: do full scan initially in force_empty Message-ID: <20200803143446.GR5174@dhcp22.suse.cz> References: <20200728074032.1555-1-laoar.shao@gmail.com> <20200730112620.GH18727@dhcp22.suse.cz> <20200803101226.GH5174@dhcp22.suse.cz> <20200803135636.GN5174@dhcp22.suse.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspamd-Queue-Id: 53C9C100E692B X-Spamd-Result: default: False [0.00 / 100.00] X-Rspamd-Server: rspam01 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Mon 03-08-20 22:18:52, Yafang Shao wrote: > On Mon, Aug 3, 2020 at 9:56 PM Michal Hocko wrote: > > > > On Mon 03-08-20 21:20:44, Yafang Shao wrote: > > > On Mon, Aug 3, 2020 at 6:12 PM Michal Hocko wrote: > > > > > > > > On Fri 31-07-20 09:50:04, Yafang Shao wrote: > > > > > On Thu, Jul 30, 2020 at 7:26 PM Michal Hocko wrote: > > > > > > > > > > > > On Tue 28-07-20 03:40:32, Yafang Shao wrote: > > > > > > > Sometimes we use memory.force_empty to drop pages in a memcg to work > > > > > > > around some memory pressure issues. When we use force_empty, we want the > > > > > > > pages can be reclaimed ASAP, however force_empty reclaims pages as a > > > > > > > regular reclaimer which scans the page cache LRUs from DEF_PRIORITY > > > > > > > priority and finally it will drop to 0 to do full scan. That is a waste > > > > > > > of time, we'd better do full scan initially in force_empty. > > > > > > > > > > > > Do you have any numbers please? > > > > > > > > > > > > > > > > Unfortunately the number doesn't improve obviously, while it is > > > > > directly proportional to the numbers of total pages to be scanned. > > > > > > > > Your changelog claims an optimization and that should be backed by some > > > > numbers. It is true that reclaim at a higher priority behaves slightly > > > > and subtly differently but that urge for even more details in the > > > > changelog. > > > > > > > > > > With the below addition change (nr_to_scan also changed), the elapsed > > > time of force_empty can be reduced by 10%. > > > > > > @@ -3208,6 +3211,7 @@ static inline bool memcg_has_children(struct > > > mem_cgroup *memcg) > > > static int mem_cgroup_force_empty(struct mem_cgroup *memcg) > > > { > > > int nr_retries = MEM_CGROUP_RECLAIM_RETRIES; > > > + unsigned long size; > > > > > > /* we call try-to-free pages for make this cgroup empty */ > > > lru_add_drain_all(); > > > @@ -3215,14 +3219,15 @@ static int mem_cgroup_force_empty(struct > > > mem_cgroup *memcg) > > > drain_all_stock(memcg); > > > /* try to free all pages in this cgroup */ > > > - while (nr_retries && page_counter_read(&memcg->memory)) { > > > + while (nr_retries && (size = page_counter_read(&memcg->memory))) { > > > int progress; > > > > > > if (signal_pending(current)) > > > return -EINTR; > > > - progress = try_to_free_mem_cgroup_pages(memcg, 1, > > > - GFP_KERNEL, true); > > > + progress = try_to_free_mem_cgroup_pages(memcg, size, > > > + GFP_KERNEL, true, > > > + 0); > > > > Have you tried this change without changing the reclaim priority? > > > > I tried it again. Seems the improvement is mostly due to the change of > nr_to_reclaim, rather the reclaim priority, > > - progress = try_to_free_mem_cgroup_pages(memcg, 1, > + progress = try_to_free_mem_cgroup_pages(memcg, size, This is what I've expected. The reclaim priority might have some side effects as well but that requires very specific conditions when the reclaim really has to dive to large scan windows to make some progress. It would be interesting to find out where the improvement comes from and how stable those numbers are. Because normally it shouldn't matter much whether you make N rounds over the reclaim with a smaller target or do the reclaim in a single round. -- Michal Hocko SUSE Labs