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 Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id E5040C433F5 for ; Tue, 8 Mar 2022 23:59:16 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 63D068D0002; Tue, 8 Mar 2022 18:59:16 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 5C4F48D0001; Tue, 8 Mar 2022 18:59:16 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 465448D0002; Tue, 8 Mar 2022 18:59:16 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0248.hostedemail.com [216.40.44.248]) by kanga.kvack.org (Postfix) with ESMTP id 3376B8D0001 for ; Tue, 8 Mar 2022 18:59:16 -0500 (EST) Received: from smtpin25.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay05.hostedemail.com (Postfix) with ESMTP id E377E1828A7F0 for ; Tue, 8 Mar 2022 23:59:15 +0000 (UTC) X-FDA: 79222887870.25.9F71FA5 Received: from mail-ej1-f51.google.com (mail-ej1-f51.google.com [209.85.218.51]) by imf03.hostedemail.com (Postfix) with ESMTP id 66B5C2000C for ; Tue, 8 Mar 2022 23:59:15 +0000 (UTC) Received: by mail-ej1-f51.google.com with SMTP id p15so1352135ejc.7 for ; Tue, 08 Mar 2022 15:59:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux-foundation.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=BVNrGCcOfvHiAcGFTY5YLY7Z1HHPIFngZYQsO1KxKDY=; b=SG8/miPNs2SqQ8nycTJeRar97B4Q7FMFusbGeyij2z7w6RORJwBq1pHwdtxhXCkrRP 31vF6vX9uuDq2YbmdD68fWT0Gox8vxJsIr/Xdf2NdLBT+tW3RUdzKm+1mBy81yu0fuoT DDi5tUBGsrtwdVz6rvkrIvBZrf5rTovzb5E7U= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=BVNrGCcOfvHiAcGFTY5YLY7Z1HHPIFngZYQsO1KxKDY=; b=ojDPqU2HjSaLrvyuxxVuWY9GjLHQRz9QcEsT8nLuTwjBm2Qp23yAfa7T4pAP8l/lgp 6AEv8S7m1L0tK0VZmO1/+mUyCneBS87i+LwEXVf778eSA9OBFG4odNYsnhoz/s+moX7w 38k/z5XfGz+Y3sL9ar5LSihIa5PVn2Orb63ls+ySVAcOGKz5KBqvuDnQFv+TUO0r/tcz gOaT3KDC0Bd+XkScx+y4/ko1ddoDb2MJTppg8qWPhGC34/nLvsuRxoWeqQ48yl93EoHL 4pY/+n33FYzZjy1604AjEL26xRzrqqz16nsHjFS7imBxido5fTCPraHI2YoSXdCjnPOf Uwbw== X-Gm-Message-State: AOAM53223WFLZv/Ii4CAyvQAgvB1ncK7tiBqwoeqxBB6uXoWTqw9IGGj UGUx2Y+54L3aOv2+E/H57Z/dQXdcTDNoxfoGx+Q= X-Google-Smtp-Source: ABdhPJyIXaR19auwp5dw2hyJrN0Io5NwL8bFgF/Kuf18tjoXAvb/nSgoEjdCkMkwHra04otfdx3SlQ== X-Received: by 2002:a17:907:970a:b0:6d9:b303:58a3 with SMTP id jg10-20020a170907970a00b006d9b30358a3mr15848900ejc.224.1646783953768; Tue, 08 Mar 2022 15:59:13 -0800 (PST) Received: from mail-ej1-f46.google.com (mail-ej1-f46.google.com. [209.85.218.46]) by smtp.gmail.com with ESMTPSA id fy1-20020a1709069f0100b006d229ed7f30sm87370ejc.39.2022.03.08.15.59.11 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 08 Mar 2022 15:59:12 -0800 (PST) Received: by mail-ej1-f46.google.com with SMTP id qx21so1292351ejb.13 for ; Tue, 08 Mar 2022 15:59:11 -0800 (PST) X-Received: by 2002:a2e:924d:0:b0:246:370c:5618 with SMTP id v13-20020a2e924d000000b00246370c5618mr12145935ljg.358.1646783940635; Tue, 08 Mar 2022 15:59:00 -0800 (PST) MIME-Version: 1.0 References: <20220308234723.3834941-1-yuzhao@google.com> <20220308234723.3834941-6-yuzhao@google.com> In-Reply-To: <20220308234723.3834941-6-yuzhao@google.com> From: Linus Torvalds Date: Tue, 8 Mar 2022 15:58:44 -0800 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH v8 05/14] mm: multi-gen LRU: groundwork To: Yu Zhao Cc: Andrew Morton , Andi Kleen , Aneesh Kumar , Catalin Marinas , Dave Hansen , Hillf Danton , Jens Axboe , Jesse Barnes , Johannes Weiner , Jonathan Corbet , Matthew Wilcox , Mel Gorman , Michael Larabel , Michal Hocko , Mike Rapoport , Rik van Riel , Vlastimil Babka , Will Deacon , Ying Huang , Linux ARM , "open list:DOCUMENTATION" , Linux Kernel Mailing List , Linux-MM , page-reclaim@google.com, "the arch/x86 maintainers" , Brian Geffon , Jan Alexander Steffens , Oleksandr Natalenko , Steven Barrett , Suleiman Souhlal , Daniel Byrne , Donald Carr , =?UTF-8?Q?Holger_Hoffst=C3=A4tte?= , Konstantin Kharlamov , Shuang Zhai , Sofia Trinh , Vaibhav Jain Content-Type: text/plain; charset="UTF-8" X-Rspamd-Server: rspam06 X-Rspamd-Queue-Id: 66B5C2000C X-Stat-Signature: 1dwdokgksbksngw9t4it7zbzfieyx4ri Authentication-Results: imf03.hostedemail.com; dkim=pass header.d=linux-foundation.org header.s=google header.b="SG8/miPN"; spf=pass (imf03.hostedemail.com: domain of torvalds@linuxfoundation.org designates 209.85.218.51 as permitted sender) smtp.mailfrom=torvalds@linuxfoundation.org; dmarc=none X-Rspam-User: X-HE-Tag: 1646783955-162035 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: I still think this part is fundamentally wrong: On Tue, Mar 8, 2022 at 3:48 PM Yu Zhao wrote: > > diff --git a/mm/Kconfig b/mm/Kconfig > index 3326ee3903f3..4ef67f157374 100644 > --- a/mm/Kconfig > +++ b/mm/Kconfig > @@ -892,6 +892,28 @@ config ANON_VMA_NAME > area from being merged with adjacent virtual memory areas due to the > difference in their name. > > +# the multi-gen LRU { > +config LRU_GEN > + bool "Multi-Gen LRU" > + depends on MMU > + # the following options can use up the spare bits in page flags > + depends on !MAXSMP && (64BIT || !SPARSEMEM || SPARSEMEM_VMEMMAP) > + help > + A high performance LRU implementation for memory overcommit. > + > +config NR_LRU_GENS > + int "Max number of generations" > + depends on LRU_GEN > + range 4 31 > + default 4 > + help > + Do not increase this value unless you plan to use working set > + estimation and proactive reclaim. These features are usually for job > + scheduling optimizations in data centers. > + > + This option uses order_base_2(N+1) bits in page flags. > +# } Pick a value. Don't ask a user for a value. If you don't know what the value should be, the user sure as hell doesn't. And if you don't pick a value for people to test, then people will test random values and dilute and make the testing less valid in the process. There is absolutely no upside to asking people a question like this, and only downsides. If the quoted "schedulign optimizations" are real, then maybe bigger values should be the default? Or maybe it should be a run-time tunable, so that people can actually _test_ them? Or - more likely - that config variable just shouldn't exist, at least in some initial series, and you just should say "we use four generations, we can tweak this if people have hard numbers later". Linus