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=-2.2 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 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 4ECC8C3F2D1 for ; Wed, 4 Mar 2020 10:56:18 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 1A00E2166E for ; Wed, 4 Mar 2020 10:56:18 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 1A00E2166E Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=suse.de Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id B921E6B0003; Wed, 4 Mar 2020 05:56:17 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id B1B3E6B0005; Wed, 4 Mar 2020 05:56:17 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id A0A506B0006; Wed, 4 Mar 2020 05:56:17 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0239.hostedemail.com [216.40.44.239]) by kanga.kvack.org (Postfix) with ESMTP id 863FB6B0003 for ; Wed, 4 Mar 2020 05:56:17 -0500 (EST) Received: from smtpin16.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay05.hostedemail.com (Postfix) with ESMTP id 01330181AC9C6 for ; Wed, 4 Mar 2020 10:56:17 +0000 (UTC) X-FDA: 76557375594.16.part63_36c9159036743 X-HE-Tag: part63_36c9159036743 X-Filterd-Recvd-Size: 4574 Received: from mx2.suse.de (mx2.suse.de [195.135.220.15]) by imf17.hostedemail.com (Postfix) with ESMTP for ; Wed, 4 Mar 2020 10:56:16 +0000 (UTC) X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.220.254]) by mx2.suse.de (Postfix) with ESMTP id D54F9B080; Wed, 4 Mar 2020 10:56:14 +0000 (UTC) Date: Wed, 4 Mar 2020 10:56:07 +0000 From: Mel Gorman To: Michal Hocko Cc: "Huang, Ying" , David Hildenbrand , Johannes Weiner , Matthew Wilcox , Andrew Morton , linux-mm@kvack.org, linux-kernel@vger.kernel.org, Vlastimil Babka , Zi Yan , Peter Zijlstra , Dave Hansen , Minchan Kim , Hugh Dickins , Alexander Duyck Subject: Re: [RFC 0/3] mm: Discard lazily freed pages when migrating Message-ID: <20200304105607.GF3772@suse.de> References: <871rqf850z.fsf@yhuang-dev.intel.com> <20200228094954.GB3772@suse.de> <87h7z76lwf.fsf@yhuang-dev.intel.com> <20200302151607.GC3772@suse.de> <87zhcy5hoj.fsf@yhuang-dev.intel.com> <20200303080945.GX4380@dhcp22.suse.cz> <87o8td4yf9.fsf@yhuang-dev.intel.com> <20200303085805.GB4380@dhcp22.suse.cz> <87ftep4pzy.fsf@yhuang-dev.intel.com> <20200304095802.GE16139@dhcp22.suse.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-15 Content-Disposition: inline In-Reply-To: <20200304095802.GE16139@dhcp22.suse.cz> User-Agent: Mutt/1.10.1 (2018-07-13) 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 Wed, Mar 04, 2020 at 10:58:02AM +0100, Michal Hocko wrote: > > >> If my understanding were correct, the newly migrated clean MADV_FREE > > >> pages will be put at the head of inactive file LRU list instead of the > > >> tail. So it's possible that some useful file cache pages will be > > >> reclaimed. > > > > > > This is the case also when you migrate other pages, right? We simply > > > cannot preserve the aging. > > > > So you consider the priority of the clean MADV_FREE pages is same as > > that of page cache pages? > > This is how MADV_FREE has been implemented, yes. See f7ad2a6cb9f7 ("mm: > move MADV_FREE pages into LRU_INACTIVE_FILE list") for the > justification. > > > Because the penalty difference is so large, I > > think it may be a good idea to always put clean MADV_FREE pages at the > > tail of the inactive file LRU list? > > You are again making assumptions without giving any actual real > examples. Reconstructing MADV_FREE pages cost can differ a lot. This > really depends on the specific usecase. Moving pages to the tail of LRU > would make them the primary candidate for the reclaim with a strange > LIFO semantic. Adding them to the head might be not the universal win > but it will at least provide a reasonable FIFO semantic. I also find > it much more easier to reason about MADV_FREE as an inactive cache. I tend to agree, that would make MADV_FREE behave more like a PageReclaim page that gets tagged for immediate reclaim when writeback completes. Immediate reclaim is in response to heavy memory pressure where there is trouble finding clean file pages to reclaim and dirty/writeback pages are getting artifically preserved over hot-but-clean file pages. That is a clear inversion of the order pages should be reclaimed and is justified. While there *might* be a basis for reclaiming MADV_FREE sooner rather than later, there would have to be some evidence of a Page inversion problem where a known hot page was getting reclaimed before MADV_FREE pages. For example, it could easily be considered a bug to free MADV_FREE pages over a page that was last touched at boot time. About the only real concern I could find about MADV_FREE is that it keeps RSS artifically high relative to MADV_DONTNEED in the absense of memory pressure. In some cases userspace provided a way of switching to MADV_DONTNEED at startup time to determine if there is a memory leak or just MADV_FREE keeping pages resident. They probably would have benefitted from a counter noting the number of MADV_FREE pages in the system as opposed to the vmstat event or some other way of distinguishing real RSS from MADV_FREE. However, I can't find a bug report indicating that MADV_FREE pages were pushing hot pages out to disk (be it file-backed or anonymous). -- Mel Gorman SUSE Labs