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 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 1C796C433E0 for ; Mon, 3 Aug 2020 10:12:30 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id B477320678 for ; Mon, 3 Aug 2020 10:12:29 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org B477320678 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 B4E588D00F5; Mon, 3 Aug 2020 06:12:29 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id AD6818D00E9; Mon, 3 Aug 2020 06:12:29 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 9C5BD8D00F5; Mon, 3 Aug 2020 06:12:29 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0205.hostedemail.com [216.40.44.205]) by kanga.kvack.org (Postfix) with ESMTP id 82AB58D00E9 for ; Mon, 3 Aug 2020 06:12:29 -0400 (EDT) Received: from smtpin05.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with ESMTP id 1EEE333C4 for ; Mon, 3 Aug 2020 10:12:29 +0000 (UTC) X-FDA: 77108842818.05.tray25_45077d526f9c Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin05.hostedemail.com (Postfix) with ESMTP id ED241180008A3 for ; Mon, 3 Aug 2020 10:12:28 +0000 (UTC) X-HE-Tag: tray25_45077d526f9c X-Filterd-Recvd-Size: 2732 Received: from mx2.suse.de (mx2.suse.de [195.135.220.15]) by imf23.hostedemail.com (Postfix) with ESMTP for ; Mon, 3 Aug 2020 10:12:28 +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 46F4DAE3A; Mon, 3 Aug 2020 10:12:42 +0000 (UTC) Date: Mon, 3 Aug 2020 12:12:26 +0200 From: Michal Hocko To: Yafang Shao Cc: Johannes Weiner , Andrew Morton , Linux MM Subject: Re: [PATCH] mm, memcg: do full scan initially in force_empty Message-ID: <20200803101226.GH5174@dhcp22.suse.cz> References: <20200728074032.1555-1-laoar.shao@gmail.com> <20200730112620.GH18727@dhcp22.suse.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspamd-Queue-Id: ED241180008A3 X-Spamd-Result: default: False [0.00 / 100.00] X-Rspamd-Server: rspam03 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 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. > But then I notice that force_empty will try to write dirty pages, that > is not expected by us, because this behavior may be dangerous in the > production environment. I do not understand your claim here. Direct reclaim doesn't write dirty page cache pages directly. And it is even less clear why that would be dangerous if it did. > What do you think introducing per memcg drop_cache ? I do not like the global drop_cache and per memcg is not very much different. This all shouldn't be really necessary because we do have means to reclaim memory in a memcg. -- Michal Hocko SUSE Labs