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=-13.3 required=3.0 tests=BAYES_00,DKIMWL_WL_MED, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED,USER_IN_DEF_DKIM_WL 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 D43AAC433B4 for ; Thu, 15 Apr 2021 07:13:28 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 76D74611CD for ; Thu, 15 Apr 2021 07:13:28 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 76D74611CD Authentication-Results: mail.kernel.org; dmarc=fail (p=reject dis=none) header.from=google.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id F23C06B0036; Thu, 15 Apr 2021 03:13:27 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id EABE76B006C; Thu, 15 Apr 2021 03:13:27 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id CFDD76B0070; Thu, 15 Apr 2021 03:13:27 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0130.hostedemail.com [216.40.44.130]) by kanga.kvack.org (Postfix) with ESMTP id AFE8E6B0036 for ; Thu, 15 Apr 2021 03:13:27 -0400 (EDT) Received: from smtpin25.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with ESMTP id 6579F5DE3 for ; Thu, 15 Apr 2021 07:13:27 +0000 (UTC) X-FDA: 78033735654.25.69ABE3A Received: from mail-wr1-f54.google.com (mail-wr1-f54.google.com [209.85.221.54]) by imf19.hostedemail.com (Postfix) with ESMTP id 99FEB90009ED for ; Thu, 15 Apr 2021 07:13:10 +0000 (UTC) Received: by mail-wr1-f54.google.com with SMTP id c15so13265894wro.13 for ; Thu, 15 Apr 2021 00:13:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=ozrwQiNh1pV14CRMAHtbeUSlZoQ38ER5bTlFizbb0SA=; b=Uh1hNCZF+0AAp+xrT2Ecos8yfbD4xsxtWZ85zcGk8XZgazP8Edts9mj6FMTPhrfhSq GwYGwXfmJA7tP5P07Uot3GYNqkoFeTC7eZzzSlb49fiuvy5bz4BlbPODUzDr6P3BAPAu PQfLzYkLjVUSQFo4Eps5jYdX9cCbSPNqcB4s0innXlEa+aZycVtMK2D75q2+iHUyiz+s GOzM/PwL+SFDb9O9Et+FrFHl6M3T+QY9W/YNvrw9QRJYtU12u2A7X2seQB82u5Fder6I qUuF8vl87+cNz5cT7N+TqSNDG1cPSiArNV/X0szy9lAX3FPU2dsrF3b0tU/p+tjnHxPB RJFA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=ozrwQiNh1pV14CRMAHtbeUSlZoQ38ER5bTlFizbb0SA=; b=e1bd5D/hknCquVtGGzYkrUBiLBVV+rw6lpg+2c8h+jEwFX377Pwx6HlJMJI+sNAr1p Zj8ypUstfRbrgalEeJWD4rMlZa1OSuw1yFxy8vCNS9WaPumUQox6cUOT5KmtEqvu6TPP LPTOOVLz0HPaSUwe/EdUoTXIgFUZOTyfZVvQkVSGhCKpQPwLsuY+DMm4mgLlfRDnSQte EhbLwc0oVgcc9kbRBivLkrNT/UG9ypk6qv5PUilQATAvyNBvz/SmeUwemW4eSHDSMWBV doLiSk+y0UqMGB2xVZqcAYjBUkDgw3I1GCtPEHZ5RsrjhLreJW87p+2nlfBU4sCw19PJ lJtg== X-Gm-Message-State: AOAM531HiIDpIoyOYTPcZZLsYMc1sYlqUHfN4xqQJ9KuHi9lQ4AfVX3I TvqKCIuuHmfQerx0nDfEtJW4w/kn8GvprpajcfWSSA== X-Google-Smtp-Source: ABdhPJz/9mMzrblEELH7HCkVo0gkDLKXoDue3E4IAiSFjwEzmzoxIJFKyLFyD4ShOpd6KcTvUgX3sgjpZESTPtv+Ufo= X-Received: by 2002:adf:e381:: with SMTP id e1mr1770069wrm.323.1618470805740; Thu, 15 Apr 2021 00:13:25 -0700 (PDT) MIME-Version: 1.0 References: <20210413075155.32652-1-sjpark@amazon.de> <3ddd4f8a-8e51-662b-df11-a63a0e75b2bc@kernel.dk> <20210413231436.GF63242@dread.disaster.area> <20210414155130.GU3762101@tassilo.jf.intel.com> <20210415030002.GX3762101@tassilo.jf.intel.com> In-Reply-To: <20210415030002.GX3762101@tassilo.jf.intel.com> From: Yu Zhao Date: Thu, 15 Apr 2021 01:13:13 -0600 Message-ID: Subject: Re: [PATCH v2 00/16] Multigenerational LRU Framework To: Rik van Riel , Ying Huang Cc: Dave Chinner , Jens Axboe , SeongJae Park , Linux-MM , Andrew Morton , Benjamin Manes , Dave Hansen , Hillf Danton , Johannes Weiner , Jonathan Corbet , Joonsoo Kim , Matthew Wilcox , Mel Gorman , Miaohe Lin , Michael Larabel , Michal Hocko , Michel Lespinasse , Roman Gushchin , Rong Chen , SeongJae Park , Tim Chen , Vlastimil Babka , Yang Shi , Zi Yan , linux-kernel , lkp@lists.01.org, Kernel Page Reclaim v2 , Andi Kleen Content-Type: text/plain; charset="UTF-8" X-Rspamd-Server: rspam01 X-Rspamd-Queue-Id: 99FEB90009ED X-Stat-Signature: fetnp81wgugwg5y3am8iiw6i41kfihid Received-SPF: none (google.com>: No applicable sender policy available) receiver=imf19; identity=mailfrom; envelope-from=""; helo=mail-wr1-f54.google.com; client-ip=209.85.221.54 X-HE-DKIM-Result: pass/pass X-HE-Tag: 1618470790-675743 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, Apr 14, 2021 at 9:00 PM Andi Kleen wrote: > > > We fall back to the rmap when it's obviously not smart to do so. There > > is still a lot of room for improvement in this function though, i.e., > > it should be per VMA and NUMA aware. > > Okay so it's more a question to tune the cross over heuristic. That > sounds much easier than replacing everything. > > Of course long term it might be a problem to maintain too many > different ways to do things, but I suppose short term it's a reasonable > strategy. Hi Rik, Ying, Sorry for being persistent. I want to make sure we are on the same page: Page table scanning doesn't replace the existing rmap walk. It is complementary and only happens when it is likely that most of the pages on a system under pressure have been referenced, i.e., out of *inactive* pages, by definition of the existing implementation. Under such a condition, scanning *active* pages one by one with the rmap is likely to cost more than scanning them all at once via page tables. When we evict *inactive* pages, we still use the rmap and share a common path with the existing code. Page table scanning falls back to the rmap walk if the page tables of a process are apparently sparse, i.e., rss < size of the page tables. I should have clarified this at the very beginning of the discussion. But it has become so natural to me and I assumed we'd all see it this way. Your concern regarding the NUMA optimization is still valid, and it's a high priority. Thanks.