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 B651AC433EF for ; Wed, 9 Mar 2022 01:13:36 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230167AbiCIBOb (ORCPT ); Tue, 8 Mar 2022 20:14:31 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:34990 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231298AbiCIBNK (ORCPT ); Tue, 8 Mar 2022 20:13:10 -0500 Received: from mail-lf1-x12b.google.com (mail-lf1-x12b.google.com [IPv6:2a00:1450:4864:20::12b]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 8654A15879C for ; Tue, 8 Mar 2022 16:56:18 -0800 (PST) Received: by mail-lf1-x12b.google.com with SMTP id g17so1041338lfh.2 for ; Tue, 08 Mar 2022 16:56:18 -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=dlXc7nO4VVenbG9TQJ/z1TWtkG9nDmF64Ost29V8AWc=; b=fk9Kkf3UiaboVe5n2sPqRmsu9R/9pSJ0MBG82T7odsoD9Z+4tUrGity1EBUSVcd5bO Ay+GVgtTlqOjk5DG157lanciRnAlDA9OLu41FZ3ehebtgoQkdRl4IX3y8PNM/lSEI5AP dZRPNM6mHBzmKNa87ZpX/gBVrjQgnOz7vbrW0= 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=dlXc7nO4VVenbG9TQJ/z1TWtkG9nDmF64Ost29V8AWc=; b=YGVD+Q+fiXunJmLZ9gPqdq8JYgj6Lh8fq+bo0Qf+p/ZSYcLunbN770b/VuV/9+Jb/d 6dLWyNLNPTSDUNxUNf4mg8ojEmJSD7CmITpYFAZDaKQbMze3Hss/auYsP7X7lL1u1dWi UvG2ugBEuZOAWy3HSaRrRm7PzG+FIz8mgK8peQshaDWlH3W5jvyJJUD6XtkHDbY4jFrA 6bJBjtNNYW+IiKjWzIdnSy8qlelTODVjZHrgcOqcyHRKJuMca52y13yYmoBf1wNmQxYZ 5q5Iq6H3L0TFe6Dju7LOLafXzkl+2AjBr1ltbt/Xz5jIQqh2LiS2xKzLfnRwcYWrjeAg f1Hw== X-Gm-Message-State: AOAM532X51eiNjtOaPa40+DaR7GCDVMalmv7S8nMN1mKm6l1fuHVWGZA Q1fvWw72uRToJ3a0JShoQMqr9/aI6tCAO6mKCAg= X-Google-Smtp-Source: ABdhPJzxiKdZrGW/psZjQD22B72hrb/aK1eFi029KadW+xrT0pF3YkWVx9q/DroWJTM77OJuzqILRA== X-Received: by 2002:a17:906:a148:b0:6cd:50c7:8d4d with SMTP id bu8-20020a170906a14800b006cd50c78d4dmr15512508ejb.641.1646785800129; Tue, 08 Mar 2022 16:30:00 -0800 (PST) Received: from mail-ej1-f43.google.com (mail-ej1-f43.google.com. [209.85.218.43]) by smtp.gmail.com with ESMTPSA id r6-20020a1709064d0600b006da7ca3e514sm98042eju.208.2022.03.08.16.29.59 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 08 Mar 2022 16:29:59 -0800 (PST) Received: by mail-ej1-f43.google.com with SMTP id p15so1468953ejc.7 for ; Tue, 08 Mar 2022 16:29:59 -0800 (PST) X-Received: by 2002:ac2:44a4:0:b0:445:8fc5:a12a with SMTP id c4-20020ac244a4000000b004458fc5a12amr12499712lfm.27.1646785789558; Tue, 08 Mar 2022 16:29:49 -0800 (PST) MIME-Version: 1.0 References: <20220308234723.3834941-1-yuzhao@google.com> In-Reply-To: From: Linus Torvalds Date: Tue, 8 Mar 2022 16:29:33 -0800 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH v8 00/14] Multi-Gen LRU Framework 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 , Kernel Page Reclaim v2 , "the arch/x86 maintainers" Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Mar 8, 2022 at 4:15 PM Yu Zhao wrote: > > This sounds self-serving: our data centers want them, so I had to try. Heh. I'm not opposed to putting them back in, but if/when we merge the multi-gen LRU code, I really want people to be all testing the same thing. I also think that if we put them back in, that should come with (a) performance numbers for the different cases (b) hard guidance of what the numbers should be, and under what circumstances (ie giving the user enough information that he *can* answer the question for his configuration) (c) some thought about perhaps making them possibly more dynamic than a hardcoded build-time value (assuming the numbers show that it's worth doing in the first place, of course) so I think that the support for the concept can/should be left in, but I think that kind of fancy "I want more generations or fewer tiers-per-generation because of XYZ" needs to be a separate issue with more explanation from the initial "This multi-gen LRU gives better performance" merge. Because as-is, I don't think those config options had nearly enough information associated with them to merit them existing. 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 82C9EC433EF for ; Wed, 9 Mar 2022 00:31:47 +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=rXrAJo32Hs8y4LXpyhxUj7Ar/YOU74wWpjC9tnckq2Y=; b=pm9XdjHa8+g2fO Y8jJiD40mjwBvY3dFmC10M3DvY1S1uqmOTpZYLDBqcBI6uGs1aDi02BaUJ3ddKf+kThqoTfea8AIl 7FkLr/Bn2P+TsSNaVvrPpmPjUZS7ctL0FD5qoamKus0Q9Y5KYydbuXHkGdoC3AY0QFo8xH3BH/lkw 6lSK4iy4GYuk9XsRw7FVkxhotAsHpr7rApkNaijScQy1oaJ6vM56E91RNBNpcFGtYYNhPZZJiDmfS fsgKMoYcE5M2t4FvrOwVvnxe+nLchUMgD0aPrMxk6LmLkHKRQ/ZlRhngCGBAcmS4PUmCOFGZdhTqd esiTF6eao3WItr3oQtPw==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1nRkDP-006jb2-FO; Wed, 09 Mar 2022 00:30:07 +0000 Received: from mail-ej1-x635.google.com ([2a00:1450:4864:20::635]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1nRkDL-006jZw-CW for linux-arm-kernel@lists.infradead.org; Wed, 09 Mar 2022 00:30:04 +0000 Received: by mail-ej1-x635.google.com with SMTP id hw13so1449962ejc.9 for ; Tue, 08 Mar 2022 16:30:01 -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=dlXc7nO4VVenbG9TQJ/z1TWtkG9nDmF64Ost29V8AWc=; b=fk9Kkf3UiaboVe5n2sPqRmsu9R/9pSJ0MBG82T7odsoD9Z+4tUrGity1EBUSVcd5bO Ay+GVgtTlqOjk5DG157lanciRnAlDA9OLu41FZ3ehebtgoQkdRl4IX3y8PNM/lSEI5AP dZRPNM6mHBzmKNa87ZpX/gBVrjQgnOz7vbrW0= 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=dlXc7nO4VVenbG9TQJ/z1TWtkG9nDmF64Ost29V8AWc=; b=FuYwAewQgqNzyi8qwCIZQv3z5LMdeHEKmjYSlI+3Ai9hR+Pducw9IWYolBVVSKOZmD 8T9fC/Rj45bvMZ1GKDH9+cByeXPX6yzXbY2ppT7zK7Rqy/4Coav2SSa79uVpy1nYnFiO HFm0JX5V+N7xmtpck5W5nL4kMzkuipuIHxSQ4nrciHJLrEprpi61l58kR8rbA607epQM OcLx5ng+UpepY6XXhuuWdVTsxDC/oTRhL8UodjStL/MKOcP0AGErFXB1W0QOlbsE2wht 1Lsobj7QKUWudnkQgYOo9f3LYpclKZtbu5+7XKkliE1526OZzVYcEgEflB5eqXEjqI2R 7H1Q== X-Gm-Message-State: AOAM531ggngie5cqgl+L4GecKPHYHu4QwYis0U+3WNP/CkLngCN9NX8t 5UrDmQeKGjieU53v0qzFHXdJ3ZrbM/i5aYNkc+Q= X-Google-Smtp-Source: ABdhPJwz+JA88WAJnIQ1y/0173+/k/voBIpE3CQcaEiSbeikxLQ5360XnVsReCCnvDiR+EeoCWinyA== X-Received: by 2002:a17:907:1b27:b0:6d9:ceb6:7967 with SMTP id mp39-20020a1709071b2700b006d9ceb67967mr15882703ejc.186.1646785800322; Tue, 08 Mar 2022 16:30:00 -0800 (PST) Received: from mail-wr1-f49.google.com (mail-wr1-f49.google.com. [209.85.221.49]) by smtp.gmail.com with ESMTPSA id fd16-20020a1709072a1000b006d90b4c029asm106164ejc.28.2022.03.08.16.30.00 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 08 Mar 2022 16:30:00 -0800 (PST) Received: by mail-wr1-f49.google.com with SMTP id r6so173705wrr.2 for ; Tue, 08 Mar 2022 16:30:00 -0800 (PST) X-Received: by 2002:ac2:44a4:0:b0:445:8fc5:a12a with SMTP id c4-20020ac244a4000000b004458fc5a12amr12499712lfm.27.1646785789558; Tue, 08 Mar 2022 16:29:49 -0800 (PST) MIME-Version: 1.0 References: <20220308234723.3834941-1-yuzhao@google.com> In-Reply-To: From: Linus Torvalds Date: Tue, 8 Mar 2022 16:29:33 -0800 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH v8 00/14] Multi-Gen LRU Framework 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 , Kernel Page Reclaim v2 , "the arch/x86 maintainers" X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20220308_163003_455838_27B55515 X-CRM114-Status: GOOD ( 14.58 ) 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 On Tue, Mar 8, 2022 at 4:15 PM Yu Zhao wrote: > > This sounds self-serving: our data centers want them, so I had to try. Heh. I'm not opposed to putting them back in, but if/when we merge the multi-gen LRU code, I really want people to be all testing the same thing. I also think that if we put them back in, that should come with (a) performance numbers for the different cases (b) hard guidance of what the numbers should be, and under what circumstances (ie giving the user enough information that he *can* answer the question for his configuration) (c) some thought about perhaps making them possibly more dynamic than a hardcoded build-time value (assuming the numbers show that it's worth doing in the first place, of course) so I think that the support for the concept can/should be left in, but I think that kind of fancy "I want more generations or fewer tiers-per-generation because of XYZ" needs to be a separate issue with more explanation from the initial "This multi-gen LRU gives better performance" merge. Because as-is, I don't think those config options had nearly enough information associated with them to merit them existing. Linus _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel