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.6 required=3.0 tests=BAYES_00,DKIM_INVALID, DKIM_SIGNED,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 32A0EC433E0 for ; Tue, 16 Mar 2021 17:02:25 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id C127565107 for ; Tue, 16 Mar 2021 17:02:24 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org C127565107 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=infradead.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 365956B006E; Tue, 16 Mar 2021 13:02:24 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 314E76B0070; Tue, 16 Mar 2021 13:02:24 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 18EA26B0071; Tue, 16 Mar 2021 13:02:24 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0039.hostedemail.com [216.40.44.39]) by kanga.kvack.org (Postfix) with ESMTP id EA0ED6B006E for ; Tue, 16 Mar 2021 13:02:23 -0400 (EDT) Received: from smtpin27.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay05.hostedemail.com (Postfix) with ESMTP id A9B88181AF5E6 for ; Tue, 16 Mar 2021 17:02:23 +0000 (UTC) X-FDA: 77926355766.27.B36C33D Received: from casper.infradead.org (casper.infradead.org [90.155.50.34]) by imf12.hostedemail.com (Postfix) with ESMTP id 3FD722BCE for ; Tue, 16 Mar 2021 17:02:17 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=casper.20170209; h=In-Reply-To:Content-Type:MIME-Version: References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description; bh=garaw7nLATePLtgkpZrGbhONhmMZwtuDPbU6Qhsl7Ow=; b=PaihaR5dpl3fXlb0g5BPWuOqqt fsWPlPNZbrV9tE0ua8idQIyBSP9NgaE3nL1JJb9oTYq3hG1PwG2L10BHcn4czOJpNPdNMLyDA/pAN ONzous7FSTl8hBwmT9sdsWd0+rI6lLG7Pawy9KJ5SLTOLakjtoLWFYYBtlZNMu/TPoKj079YxI1L6 K3KID+ReEE+e6G84LcZ8hVwpUGwA1yTplXQwDGZjuNwPw9IjS80q+QBUy4rZ3dteYsJj3RlrOENEP RDsNsmxj2UnWZN4frcmVlAlsys3jNolzaLZa9OIZKsYaB0XTgxL+vGfSVQkg9lWww9/IgyNSSyHoU HpDXNl4g==; Received: from willy by casper.infradead.org with local (Exim 4.94 #2 (Red Hat Linux)) id 1lMCeT-000Jql-OC; Tue, 16 Mar 2021 16:34:41 +0000 Date: Tue, 16 Mar 2021 16:34:37 +0000 From: Matthew Wilcox To: Yu Zhao Cc: linux-mm@kvack.org, Alex Shi , Andrew Morton , Dave Hansen , Hillf Danton , Johannes Weiner , Joonsoo Kim , Mel Gorman , Michal Hocko , Roman Gushchin , Vlastimil Babka , Wei Yang , Yang Shi , Ying Huang , linux-kernel@vger.kernel.org, page-reclaim@google.com Subject: Re: [PATCH v1 11/14] mm: multigenerational lru: page activation Message-ID: <20210316163437.GB3420@casper.infradead.org> References: <20210313075747.3781593-1-yuzhao@google.com> <20210313075747.3781593-12-yuzhao@google.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20210313075747.3781593-12-yuzhao@google.com> X-Stat-Signature: 9f1tromf73u8htfa1s8g3mp5dp5dmrjs X-Rspamd-Server: rspam02 X-Rspamd-Queue-Id: 3FD722BCE Received-SPF: none (infradead.org>: No applicable sender policy available) receiver=imf12; identity=mailfrom; envelope-from=""; helo=casper.infradead.org; client-ip=90.155.50.34 X-HE-DKIM-Result: pass/pass X-HE-Tag: 1615914137-320014 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 Sat, Mar 13, 2021 at 12:57:44AM -0700, Yu Zhao wrote: > In the page fault path, we want to add pages to the per-zone lists > index by max_seq as they cannot be evicted without going through > the aging first. For anon pages, we rename > lru_cache_add_inactive_or_unevictable() to lru_cache_add_page_vma() > and add a new parameter, which is set to true in the page fault path, > to indicate whether they should be added to the per-zone lists index > by max_seq. For page/swap cache, since we cannot differentiate the > page fault path from the read ahead path at the time we call > lru_cache_add() in add_to_page_cache_lru() and > __read_swap_cache_async(), we have to add a new function > lru_gen_activate_page(), which is essentially activate_page(), to move > pages to the per-zone lists indexed by max_seq at a later time. > Hopefully we would find pages we want to activate in lru_pvecs.lru_add > and simply set PageActive() on them without having to actually move > them. > > In the reclaim path, pages mapped around a referenced PTE may also > have been referenced due to spatial locality. We add a new function > lru_gen_scan_around() to scan the vicinity of such a PTE. > > In addition, we add a new function page_is_active() to tell whether a > page is active. We cannot use PageActive() because it is only set on > active pages while they are not on multigenerational lru. It is > cleared while pages are on multigenerational lru, in order to spare > the aging the trouble of clearing it when an active generation becomes > inactive. Internally, page_is_active() compares the generation number > of a page with max_seq and max_seq-1, which are active generations and > protected from the eviction. Other generations, which may or may not > exist, are inactive. If we go with this multi-LRU approach, it feels like PageActive and PageInactive should go away as tests. We should have a LRU field in the page flags with some special values: - Not managed through LRU list - Not currently on any LRU list - Unevictable - Active list 1 - Active list 2 - ... - Active list 5 Now you don't need any extra bits in the page flags. Or if you want to have 13 lists instead of 5, you can use just one extra bit. I'm not quite sure whether it makes sense to have that many lists, so I need to try to understand that better. I'd like to echo the comments from others that it'd be nice to split apart the multigenerational part of this and the physical scanning part of this. It's possible they don't make performance sense without each other, but from a review point of view, they seem entirely separate things.