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 vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 99694C433F5 for ; Wed, 9 Mar 2022 01:16:45 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230189AbiCIBRl (ORCPT ); Tue, 8 Mar 2022 20:17:41 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:52318 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230270AbiCIBRB (ORCPT ); Tue, 8 Mar 2022 20:17:01 -0500 Received: from mail-lj1-x22d.google.com (mail-lj1-x22d.google.com [IPv6:2a00:1450:4864:20::22d]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 7F8221C125 for ; Tue, 8 Mar 2022 17:07:03 -0800 (PST) Received: by mail-lj1-x22d.google.com with SMTP id h11so1001964ljb.2 for ; Tue, 08 Mar 2022 17:07:03 -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=HULZkjVdYtQBbxTlaOD5zDuQ5TaqWaJ2N5TtFIkjolAFfC6GlBZBamA1Gq14327IfM oKHGpHorjA+ecPwcmkiyAfzqFBCwCVcgG75RServbnf6ij4509ixcKPsCKteY56bX2Nn KK9xnYvX6ZE0IFr1I/2I1bTvxJfbVTILvGtDRV71WwLyQx0Wsa66cF/JLf4heLq4Y2aN 4aLdCRpw9E8A1MmWLFv0EJXyybpZoomhiV0B0AGNgC9X9GNCzfh0wErDeFqmnjBdSMuD aYdul+inArKBV/rrVVkUumr2USz0KJBEMRx6TY6wBVeRsDe8h/Vuu7RJ5WsRFUvTlN3G bkjg== X-Gm-Message-State: AOAM533DgkIxdSUrTCNkQ5Imu+wMiJTH7uvc5rE/jQi2q+tq+7+gmq6K /wUP9Egkx6HfjdgdNqPVmfNJzV5l/4hk2Z8yKK0= X-Google-Smtp-Source: ABdhPJx6AWqrHOVly8fQhiPxze4QcU+7vA0PYzffwjLDU90qzRXd1euF1Z2zesQMKoDRH45N1MgEQQ== X-Received: by 2002:a17:906:7745:b0:6b5:fe2b:4827 with SMTP id o5-20020a170906774500b006b5fe2b4827mr15214443ejn.628.1646783951712; Tue, 08 Mar 2022 15:59:11 -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 h7-20020a1709066d8700b006d4b4d137fbsm86756ejt.50.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:11 -0800 (PST) Received: by mail-ej1-f46.google.com with SMTP id p15so1351947ejc.7 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" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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 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 bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 05CEDC433F5 for ; Wed, 9 Mar 2022 00:01:04 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:Cc:To:Subject:Message-ID:Date:From: In-Reply-To:References:MIME-Version:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=16nUsIepS7GfgwM8TtweFKL9pv4VAr89jUarCh1kgm8=; b=O3s3/UVDQNaFfg IaflnY1mU7LiSW2I8DO/2W8m9Uzuur7pAtEtMJM7en0wXQ5muI5RpIy3IczFguY+CkUnmMC+EcXJv 5dsuYiwJujihUMqPyz0qQt9mdzWwvcQV88ZAh2U0zddF7nZoo1vT+dX3v2yalvfaQcXap3iAmkYst JiafKi7S+3ywAomkPmg8HSRSu/zSHIFDao4OxZa6491oGjllvMFK/EokPBkBoPpbWeqpVwwBC22Ul 7BY4ZEsvMrGsnElA32XsBvVEr6ZTCXyil+q0FFrxA4TqIdzuLldIr7QcldGlejE95A/3Sz7fkIb6z 5+bW0L5FEqhn112M9tGw==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1nRjje-006eWX-0H; Tue, 08 Mar 2022 23:59:23 +0000 Received: from mail-ej1-x62b.google.com ([2a00:1450:4864:20::62b]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1nRjjU-006eTk-MW for linux-arm-kernel@lists.infradead.org; Tue, 08 Mar 2022 23:59:14 +0000 Received: by mail-ej1-x62b.google.com with SMTP id qt6so1315562ejb.11 for ; Tue, 08 Mar 2022 15:59:12 -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=RLJ2VAYRKzaj9izNyOe88y0VwWJlLT07bpQkltqxzfxldU43dtC22WWw4R/E8RgCuL UmufHNLVbCeb9IBhETjmDsMYkalpq4M6M0+XOFl8+6rJGdHwqvQP705af+VZ1ndeFcD9 MrPfrC7XyKx6H26i0aC6kmV8SIyV9uq6xBiIa+W9xgBb1zBReHIK64adTBlnkABT3SAK Hsp0/h8hMgLA6aIkuTOL6m/ozzLerUA0rVFaUVqy52GxpkznOQJzVPjSLzirsBBeuE78 ueF0VYJX4yFGsO7RW9QIWXR7owetfmgH3KtaAwdPPItHEu3IdZ1CdBMvuo4DxgXUOSzR a5YQ== X-Gm-Message-State: AOAM531exckWT4qre8zwepR+f71UL2sr+g/GDHXqJxFPiGYQs+idtPxH jGzmN1Yo0NCmvrxDvVYR4vlqfwKlLM5PaCqNe/k= X-Google-Smtp-Source: ABdhPJyKovtA141p2F7RHu3cXSkQjTBchBvHt8PyCwPkqdSNxHQ2ajGziumfPlQKoH+KxJqjPXcnqw== X-Received: by 2002:a17:907:7f0d:b0:6d6:f910:5136 with SMTP id qf13-20020a1709077f0d00b006d6f9105136mr16115090ejc.736.1646783951176; Tue, 08 Mar 2022 15:59:11 -0800 (PST) Received: from mail-ej1-f51.google.com (mail-ej1-f51.google.com. [209.85.218.51]) by smtp.gmail.com with ESMTPSA id y12-20020a50eb8c000000b00410f02e577esm108061edr.7.2022.03.08.15.59.10 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 08 Mar 2022 15:59:10 -0800 (PST) Received: by mail-ej1-f51.google.com with SMTP id p15so1351932ejc.7 for ; Tue, 08 Mar 2022 15:59:10 -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 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20220308_155912_756760_F3425832 X-CRM114-Status: GOOD ( 20.08 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org 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 _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel