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 9CADCC433FE for ; Fri, 15 Apr 2022 06:26:26 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1350434AbiDOG2v (ORCPT ); Fri, 15 Apr 2022 02:28:51 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:50608 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S237018AbiDOG2t (ORCPT ); Fri, 15 Apr 2022 02:28:49 -0400 Received: from mail-vs1-xe2c.google.com (mail-vs1-xe2c.google.com [IPv6:2607:f8b0:4864:20::e2c]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id C3645DF56 for ; Thu, 14 Apr 2022 23:26:22 -0700 (PDT) Received: by mail-vs1-xe2c.google.com with SMTP id i186so6374705vsc.9 for ; Thu, 14 Apr 2022 23:26:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=r4RShQi9icr7wSxQlh0D5L5Evfs0VvFyTLZdHUvu9L8=; b=sBwypCjbQBF+/WnqvmCEXoT4JJbp6AciTPTzeArpyy83AZyGtxPkBZkpF85m+7fkMn kPx4nv3WZ5qyoxA/4xAgWEUyUcZXrS7bf5+Eisexvk/XGpQV+k7wpEcVUB0KMptK0UZK 3yNAS7Z6y7+iNRD97p4PZILtxALsN4zNaC882fCMTlwjDoLPNjZ2GAqPEjJLPz+K3I6h l/ye5pX+ePxFIAPQxK8F3iX6fMxyHcEhpSeUCtlMdGZNny74nOsnP22k6qPrMTvdwOew /t0cYCS21NKTCj6temp6PIHBKX94uBS+QcaG0ghNHJO2Pimg8PGEILuUamsf74rauMez mMVQ== 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=r4RShQi9icr7wSxQlh0D5L5Evfs0VvFyTLZdHUvu9L8=; b=XOUrgU9r8eTNBdHgRTul/F9+H4NMX3PRsqARPgW2F7sMghP91dPB1obrYAwL76nV8N CkPprp38+KPtOoQnP8CfyDXqPlsfnHz7BcYwjzlUcN7LROH8NNaPFZI/CT+W5zRVZAnK mkU97tt1m1LfwvW2BS/IgApiM5eFPPw1uMwK7Emo+fnPDrLgCSs2gg8wpnSOSzeEKXgI rVAHkmk1dAqqHMn9yswOK/gg5HofSvbBCOs5U6d79b2xc+f6PxN5MZMwg7W3GFZL+g5t T9gkbO/WFk1OA97mffiWmcvQAejnI5z+FT72qm/SNwfv3WOXg0AnzOjNgTNDb99Fjsyg Lxgw== X-Gm-Message-State: AOAM5326I4g4y615COzXvK3mbco3qMgTWNlrMzrFUIBI2OL6/JiU1nPj aoS/KBVtpSRCN8zymJ85XumE642v1A9s+7Cv0J75Nw== X-Google-Smtp-Source: ABdhPJxMuVrw6CCgd27RYTqBzChXKJNxGSOn9st5mfjSU3MHVTrF9aapaud6/EVQrwuLVccLBrOGNcvr5Ir3CrMKYXc= X-Received: by 2002:a05:6102:5cc:b0:320:9bd2:3823 with SMTP id v12-20020a05610205cc00b003209bd23823mr2694438vsf.81.1650003981638; Thu, 14 Apr 2022 23:26:21 -0700 (PDT) MIME-Version: 1.0 References: <20220407031525.2368067-1-yuzhao@google.com> <20220407031525.2368067-9-yuzhao@google.com> <20220411191621.0378467ad99ebc822d5ad005@linux-foundation.org> <20220414185654.e7150bcbe859e0dd4b9c61af@linux-foundation.org> In-Reply-To: <20220414185654.e7150bcbe859e0dd4b9c61af@linux-foundation.org> From: Yu Zhao Date: Fri, 15 Apr 2022 00:25:45 -0600 Message-ID: Subject: Re: [PATCH v10 08/14] mm: multi-gen LRU: support page table walks To: Andrew Morton Cc: Stephen Rothwell , Linux-MM , Andi Kleen , Aneesh Kumar , Barry Song <21cnbao@gmail.com>, Catalin Marinas , Dave Hansen , Hillf Danton , Jens Axboe , Jesse Barnes , Johannes Weiner , Jonathan Corbet , Linus Torvalds , 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 , Kernel Page Reclaim v2 , "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 On Thu, Apr 14, 2022 at 7:57 PM Andrew Morton wrote: > > On Thu, 14 Apr 2022 19:14:54 -0600 Yu Zhao wrote: > > > On Mon, Apr 11, 2022 at 8:16 PM Andrew Morton wrote: > > > > > > On Wed, 6 Apr 2022 21:15:20 -0600 Yu Zhao wrote: > > > > > > > +static void update_batch_size(struct lru_gen_mm_walk *walk, struct folio *folio, > > > > + int old_gen, int new_gen) > > > > +{ > > > > + int type = folio_is_file_lru(folio); > > > > + int zone = folio_zonenum(folio); > > > > + int delta = folio_nr_pages(folio); > > > > + > > > > + VM_BUG_ON(old_gen >= MAX_NR_GENS); > > > > + VM_BUG_ON(new_gen >= MAX_NR_GENS); > > > > > > General rule: don't add new BUG_ONs, because they crash the kenrel. > > > It's better to use WARN_ON or WARN_ON_ONCE then try to figure out a way > > > to keep the kernel limping along. At least so the poor user can gather logs. > > > > These are VM_BUG_ONs, which are BUILD_BUG_ONs except for (mostly MM) developers. > > I'm told that many production builds enable runtime VM_BUG_ONning. Nobody wants to debug VM in production. Some distros that offer both the latest/LTS kernels do enable CONFIG_DEBUG_VM in the former so the latter can have better test coverage when it becomes available. Do people use the former in production? Absolutely, otherwise we won't have enough test coverage. Are we supposed to avoid CONFIG_DEBUG_VM? I don't think so, because it defeats the purpose of those distros enabling it in the first place. The bottomline is that none of RHEL 8.5, SLES 15, Debian 11 enables CONFIG_DEBUG_VM. 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 6D0E3C433F5 for ; Fri, 15 Apr 2022 06:39:12 +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=qJ+6ogKU6oAIf46/gOkVR9bGX05S1NF4wkPsB/7oXHE=; b=c4NhIv/EUnDnsJ wPJv3WhqjmF1kGg1WmsC0Xi9EwUNJZwq3UYsvtGXzuwKAEm2A+Q+nxnjRTYtpSPF5JzLsE0DwVIAy zKTeLMqsbieitL20NSQ556mrAOSYtsolAYo4rA7KAZwiZKfPsnBK49bWOQzR9/aQok0q12iZ2aOud 1GkYwi7cUsiF4ZJil/wIhqQLWthzhqOvhn8ODnZKT2SOo3HyO2eW6V4QQ6xH2cm7Io6u97Gws0j5E O5y4Lo9OBW7Iil40De3QcFSTzF3nhstPeM1OkMGEDgDZWPE2XlW66Qi8CJ+h5AJ8Rmwex8UD+NAQ9 WoK/4tgkye9qk6HtEyWA==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1nfFZs-0092eh-Bq; Fri, 15 Apr 2022 06:37:09 +0000 Received: from mail-vs1-xe31.google.com ([2607:f8b0:4864:20::e31]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1nfFPT-008yfz-Ii for linux-arm-kernel@lists.infradead.org; Fri, 15 Apr 2022 06:26:25 +0000 Received: by mail-vs1-xe31.google.com with SMTP id v15so4892249vsm.5 for ; Thu, 14 Apr 2022 23:26:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=r4RShQi9icr7wSxQlh0D5L5Evfs0VvFyTLZdHUvu9L8=; b=sBwypCjbQBF+/WnqvmCEXoT4JJbp6AciTPTzeArpyy83AZyGtxPkBZkpF85m+7fkMn kPx4nv3WZ5qyoxA/4xAgWEUyUcZXrS7bf5+Eisexvk/XGpQV+k7wpEcVUB0KMptK0UZK 3yNAS7Z6y7+iNRD97p4PZILtxALsN4zNaC882fCMTlwjDoLPNjZ2GAqPEjJLPz+K3I6h l/ye5pX+ePxFIAPQxK8F3iX6fMxyHcEhpSeUCtlMdGZNny74nOsnP22k6qPrMTvdwOew /t0cYCS21NKTCj6temp6PIHBKX94uBS+QcaG0ghNHJO2Pimg8PGEILuUamsf74rauMez mMVQ== 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=r4RShQi9icr7wSxQlh0D5L5Evfs0VvFyTLZdHUvu9L8=; b=Q+Iv/VsyCi8foKEeQFG01qX4ERP/0dUhAxMjw6/YgtGdMOKc4IcfXNUGLuIdO7iYwr fLeTSG43sZ2c4BHjGpBWvcl8XHI0mYMvMwaGJ+Vmd4Sbfn9FQ5s7dJoRs204fLXnDrtp IIovFGqqREAGp0tUBC4cZkXiNHAXePukOkqVYgaXZjAVqvWNzFFCywKmaa4qtRvDAW67 6jQZBzMzkY/X8t/sE8SXgArRnzabCu+RXnH+iW47i4sk3bT9YuMNf1p5zo6h2cl8iO3y XRkqSBSzTiuMC3IR59tdB7/h7SOXwMf0URafKmBbPHbebcsnoKmXZLq6101KFzmOZ3pm ifwg== X-Gm-Message-State: AOAM5332hzc3xk38ge9vd3274tptD5sP6wGCt1aeaL6CI2comV6pTwqB 6EZdsYihDhBn3ZLX7PyT3rzPcqi2DXaAOHfctHgnCg== X-Google-Smtp-Source: ABdhPJxMuVrw6CCgd27RYTqBzChXKJNxGSOn9st5mfjSU3MHVTrF9aapaud6/EVQrwuLVccLBrOGNcvr5Ir3CrMKYXc= X-Received: by 2002:a05:6102:5cc:b0:320:9bd2:3823 with SMTP id v12-20020a05610205cc00b003209bd23823mr2694438vsf.81.1650003981638; Thu, 14 Apr 2022 23:26:21 -0700 (PDT) MIME-Version: 1.0 References: <20220407031525.2368067-1-yuzhao@google.com> <20220407031525.2368067-9-yuzhao@google.com> <20220411191621.0378467ad99ebc822d5ad005@linux-foundation.org> <20220414185654.e7150bcbe859e0dd4b9c61af@linux-foundation.org> In-Reply-To: <20220414185654.e7150bcbe859e0dd4b9c61af@linux-foundation.org> From: Yu Zhao Date: Fri, 15 Apr 2022 00:25:45 -0600 Message-ID: Subject: Re: [PATCH v10 08/14] mm: multi-gen LRU: support page table walks To: Andrew Morton Cc: Stephen Rothwell , Linux-MM , Andi Kleen , Aneesh Kumar , Barry Song <21cnbao@gmail.com>, Catalin Marinas , Dave Hansen , Hillf Danton , Jens Axboe , Jesse Barnes , Johannes Weiner , Jonathan Corbet , Linus Torvalds , 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 , Kernel Page Reclaim v2 , "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-20220414_232623_702299_27A28976 X-CRM114-Status: GOOD ( 18.23 ) 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 Thu, Apr 14, 2022 at 7:57 PM Andrew Morton wrote: > > On Thu, 14 Apr 2022 19:14:54 -0600 Yu Zhao wrote: > > > On Mon, Apr 11, 2022 at 8:16 PM Andrew Morton wrote: > > > > > > On Wed, 6 Apr 2022 21:15:20 -0600 Yu Zhao wrote: > > > > > > > +static void update_batch_size(struct lru_gen_mm_walk *walk, struct folio *folio, > > > > + int old_gen, int new_gen) > > > > +{ > > > > + int type = folio_is_file_lru(folio); > > > > + int zone = folio_zonenum(folio); > > > > + int delta = folio_nr_pages(folio); > > > > + > > > > + VM_BUG_ON(old_gen >= MAX_NR_GENS); > > > > + VM_BUG_ON(new_gen >= MAX_NR_GENS); > > > > > > General rule: don't add new BUG_ONs, because they crash the kenrel. > > > It's better to use WARN_ON or WARN_ON_ONCE then try to figure out a way > > > to keep the kernel limping along. At least so the poor user can gather logs. > > > > These are VM_BUG_ONs, which are BUILD_BUG_ONs except for (mostly MM) developers. > > I'm told that many production builds enable runtime VM_BUG_ONning. Nobody wants to debug VM in production. Some distros that offer both the latest/LTS kernels do enable CONFIG_DEBUG_VM in the former so the latter can have better test coverage when it becomes available. Do people use the former in production? Absolutely, otherwise we won't have enough test coverage. Are we supposed to avoid CONFIG_DEBUG_VM? I don't think so, because it defeats the purpose of those distros enabling it in the first place. The bottomline is that none of RHEL 8.5, SLES 15, Debian 11 enables CONFIG_DEBUG_VM. _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel