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, 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 0250DC433C1 for ; Thu, 25 Mar 2021 04:33:59 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 744AC61A1B for ; Thu, 25 Mar 2021 04:33:58 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 744AC61A1B Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=intel.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id C9EBC6B0036; Thu, 25 Mar 2021 00:33:57 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id C4F436B006C; Thu, 25 Mar 2021 00:33:57 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id B160D6B006E; Thu, 25 Mar 2021 00:33:57 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0154.hostedemail.com [216.40.44.154]) by kanga.kvack.org (Postfix) with ESMTP id 97A456B0036 for ; Thu, 25 Mar 2021 00:33:57 -0400 (EDT) Received: from smtpin36.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay01.hostedemail.com (Postfix) with ESMTP id 432E518033D18 for ; Thu, 25 Mar 2021 04:33:57 +0000 (UTC) X-FDA: 77957128914.36.F0DE477 Received: from mga02.intel.com (mga02.intel.com [134.134.136.20]) by imf22.hostedemail.com (Postfix) with ESMTP id 793BCC0007C8 for ; Thu, 25 Mar 2021 04:33:53 +0000 (UTC) IronPort-SDR: dBdsonM8Wu41gz0AKN2yIj76D2joVrT6fE1DdbQd1uZM442GzsC6789Rk/U7pBvJf/LgDLXb2g sJ/ubdfZejeQ== X-IronPort-AV: E=McAfee;i="6000,8403,9933"; a="177964516" X-IronPort-AV: E=Sophos;i="5.81,276,1610438400"; d="scan'208";a="177964516" Received: from orsmga001.jf.intel.com ([10.7.209.18]) by orsmga101.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 24 Mar 2021 21:33:52 -0700 IronPort-SDR: tHzt6cDrvoXuM/B9IGFOlkl8C4CZ/SkFxnqjMFGxCrgd2mWO858Q7kA6kMaAfmyJxC890w06V1 zMkd7Ssg1j+g== X-IronPort-AV: E=Sophos;i="5.81,276,1610438400"; d="scan'208";a="452882743" Received: from yhuang6-desk1.sh.intel.com (HELO yhuang6-desk1.ccr.corp.intel.com) ([10.239.13.1]) by orsmga001-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 24 Mar 2021 21:33:48 -0700 From: "Huang, Ying" To: Mel Gorman Cc: , Andrew Morton , , Yu Zhao , Hillf Danton , Johannes Weiner , Joonsoo Kim , Matthew Wilcox , Michal Hocko , Roman Gushchin , Vlastimil Babka , Wei Yang , Yang Shi Subject: Re: [RFC] mm: activate access-more-than-once page via NUMA balancing References: <20210324083209.527427-1-ying.huang@intel.com> <20210324103104.GN15768@suse.de> Date: Thu, 25 Mar 2021 12:33:45 +0800 In-Reply-To: <20210324103104.GN15768@suse.de> (Mel Gorman's message of "Wed, 24 Mar 2021 10:31:04 +0000") Message-ID: <87a6qrj1hy.fsf@yhuang6-desk1.ccr.corp.intel.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=ascii X-Stat-Signature: 4z6wttrpctwg4jm1rrftppajgpoksnp3 X-Rspamd-Server: rspam02 X-Rspamd-Queue-Id: 793BCC0007C8 Received-SPF: none (intel.com>: No applicable sender policy available) receiver=imf22; identity=mailfrom; envelope-from=""; helo=mga02.intel.com; client-ip=134.134.136.20 X-HE-DKIM-Result: none/none X-HE-Tag: 1616646833-625915 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: Hi, Mel, Thanks for comment! Mel Gorman writes: > On Wed, Mar 24, 2021 at 04:32:09PM +0800, Huang Ying wrote: >> One idea behind the LRU page reclaiming algorithm is to put the >> access-once pages in the inactive list and access-more-than-once pages >> in the active list. This is true for the file pages that are accessed >> via syscall (read()/write(), etc.), but not for the pages accessed via >> the page tables. We can only activate them via page reclaim scanning >> now. This may cause some problems. For example, even if there are >> only hot file pages accessed via the page tables in the inactive list, >> we will enable the cache trim mode incorrectly to scan only the hot >> file pages instead of cold anon pages. >> > > I caution against this patch. > > It's non-deterministic for a number of reasons. As it requires NUMA > balancing to be enabled, the pageout behaviour of a system changes when > NUMA balancing is active. If this led to pages being artificially and > inappropriately preserved, NUMA balancing could be disabled for the > wrong reasons. It only applies to pages that have no target node so > memory policies affect which pages are activated differently. Similarly, > NUMA balancing does not scan all VMAs and some pages may never trap a > NUMA fault as a result. The timing of when an address space gets scanned > is driven by the locality of pages and so the timing of page activation > potentially becomes linked to whether pages are local or need to migrate > (although not right now for this patch as it only affects pages with a > target nid of NUMA_NO_NODE). In other words, changes in NUMA balancing > that affect migration potentially affect the aging rate. Similarly, > the activate rate of a process with a single thread and multiple threads > potentially have different activation rates. > > Finally, the NUMA balancing scan algorithm is sub-optimal. It potentially > scans the entire address space even though only a small number of pages > are scanned. This is particularly problematic when a process has a lot > of threads because threads are redundantly scanning the same regions. If > NUMA balancing ever introduced range tracking of faulted pages to limit > how much scanning it has to do, it would inadvertently cause a change in > page activation rate. > > NUMA balancing is about page locality, it should not get conflated with > page aging. I understand your concerns about binding the NUMA balancing and page reclaiming. The requirement of the page locality and page aging is different, so the policies need to be different. This is the wrong part of the patch. >From another point of view, it's still possible to share some underlying mechanisms (and code) between them. That is, scanning the page tables to make pages unaccessible and capture the page accesses via the page fault. Now these page accessing information is used for the page locality. Do you think it's a good idea to use these information for the page aging too (but with a different policy as you pointed out)? >From yet another point of view :-), in current NUMA balancing implementation, it's assumed that the node private pages can fit in the accessing node. But this may be not always true. Is it a valid optimization to migrate the hot private pages first? Best Regards, Huang, Ying