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=-3.8 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,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 EE67CC4741F for ; Thu, 5 Nov 2020 17:47:09 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 50A7420709 for ; Thu, 5 Nov 2020 17:47:09 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=suse.com header.i=@suse.com header.b="kPYiT67W" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 50A7420709 Authentication-Results: mail.kernel.org; dmarc=fail (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 AC58A6B0173; Thu, 5 Nov 2020 12:47:08 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id A4E806B0174; Thu, 5 Nov 2020 12:47:08 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 915A06B0175; Thu, 5 Nov 2020 12:47:08 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0167.hostedemail.com [216.40.44.167]) by kanga.kvack.org (Postfix) with ESMTP id 5C7EE6B0173 for ; Thu, 5 Nov 2020 12:47:08 -0500 (EST) Received: from smtpin01.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay03.hostedemail.com (Postfix) with ESMTP id EDC5C824999B for ; Thu, 5 Nov 2020 17:47:07 +0000 (UTC) X-FDA: 77451095694.01.kite28_4b05ae0272cb Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin01.hostedemail.com (Postfix) with ESMTP id CB352100495D7 for ; Thu, 5 Nov 2020 17:47:07 +0000 (UTC) X-HE-Tag: kite28_4b05ae0272cb X-Filterd-Recvd-Size: 3763 Received: from mx2.suse.de (mx2.suse.de [195.135.220.15]) by imf41.hostedemail.com (Postfix) with ESMTP for ; Thu, 5 Nov 2020 17:47:07 +0000 (UTC) X-Virus-Scanned: by amavisd-new at test-mx.suse.de DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1; t=1604598426; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=/UptV15xqha8EYgqDPievC09KyL0IAGv7iVFe8o7of0=; b=kPYiT67WH9oUUZeVQw9qAXoA+ef3MWMt54Pm0eRgRIi5QS32l5PnF6PuhYLoznl5pP3Ql6 I4N9WhUWQPazannrZ7jI2FZJ5sDLBhnoSryVDUO8KRRccyoRw/vKqlrChJtFv55+4zhUZw NfcZU+KpJrTCLvMA+SRNNjMMxDAya14= Received: from relay2.suse.de (unknown [195.135.221.27]) by mx2.suse.de (Postfix) with ESMTP id 11E50AD60; Thu, 5 Nov 2020 17:47:06 +0000 (UTC) Date: Thu, 5 Nov 2020 18:47:05 +0100 From: Michal Hocko To: Yafang Shao , minchan@kernel.org Cc: Andrew Morton , Johannes Weiner , Linux MM Subject: Re: [PATCH] mm: account lazily freed anon pages in NR_FILE_PAGES Message-ID: <20201105174705.GS21348@dhcp22.suse.cz> References: <20201105131012.82457-1-laoar.shao@gmail.com> <20201105133536.GJ21348@dhcp22.suse.cz> <20201105152251.GL21348@dhcp22.suse.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20201105152251.GL21348@dhcp22.suse.cz> 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 Thu 05-11-20 16:22:52, Michal Hocko wrote: > On Thu 05-11-20 22:16:10, Yafang Shao wrote: > > On Thu, Nov 5, 2020 at 9:35 PM Michal Hocko wrote: > > > > > > On Thu 05-11-20 21:10:12, Yafang Shao wrote: > > > > The memory utilization (Used / Total) is used to monitor the memory > > > > pressure by us. If it is too high, it means the system may be OOM sooner > > > > or later when swap is off, then we will make adjustment on this system. > > > > > > > > However, this method is broken since MADV_FREE is introduced, because > > > > these lazily free anonymous can be reclaimed under memory pressure while > > > > they are still accounted in NR_ANON_MAPPED. > > > > > > > > Furthermore, since commit f7ad2a6cb9f7 ("mm: move MADV_FREE pages into > > > > LRU_INACTIVE_FILE list"), these lazily free anonymous pages are moved > > > > from anon lru list into file lru list. That means > > > > (Inactive(file) + Active(file)) may be much larger than Cached in > > > > /proc/meminfo. That makes our users confused. > > > > > > > > So we'd better account the lazily freed anonoymous pages in > > > > NR_FILE_PAGES as well. > > > > > > Can you simply subtract lazyfree pages in the userspace? > > > > Could you pls. tell me how to subtract lazyfree pages in the userspace? > > Pls. note that we can't use (pglazyfree - pglazyfreed) because > > pglazyfreed is only counted in the regular reclaim path while the > > process exit path is not counted, that means we have to introduce > > another counter like LazyPage.... > > OK, I see your concern. I thought that we do update counters on a > regular unmap. I do not see any reason why we shouldn't. It is indeed > bad that we cannot tell the current number of lazy free pages by no > means. Was this deliberate Minchan? http://lkml.kernel.org/r/20201105162219.GG744831@cmpxchg.org has explained this. I completely forgot about the fact that those pages can be reused and lose their madvise status and we will learn about that only when checking the page. Thanks Johannes for clarification. -- Michal Hocko SUSE Labs