Received: by 2002:a05:6358:d09b:b0:dc:cd0c:909e with SMTP id jc27csp1070140rwb; Thu, 1 Dec 2022 11:57:54 -0800 (PST) X-Google-Smtp-Source: AA0mqf5LFmV1Xb5kVDa5dIppcvyMdl4V3gh/ZELJd+19bSRvuF7BTcXh0D4zqVQUQSVx9O68nQjw X-Received: by 2002:a17:906:52c9:b0:7c0:a699:6422 with SMTP id w9-20020a17090652c900b007c0a6996422mr6172565ejn.617.1669924673945; Thu, 01 Dec 2022 11:57:53 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1669924673; cv=none; d=google.com; s=arc-20160816; b=0LwLXOR6xBvXCPgZpZr9A4Vq9WeS3EPPU2ovRfmfqpf0j4FwbDjenptzqxEp0uFmXy cLexmwEchUMZ4u2EFrQkiu4IghlOFimYIT5JMtJ79bw6jrZrc2V5rHjCINzUDPr45GBg OfHtYQPr5ZpChWWkIYIG6pExuQ/H5+cnCF52NgamhS+mJl0KHk3N4sUNkTnt8DUjvTOB NguURVxO2ylOdJAfnf4h8Hed7Ux5L6e2fHAZjzj2dgVAX/HpzP1FluweDZKMr8OhWE/h qezQk3w/uc6wj2LqmXq+cp4ZJNN/iyQbT7k3RJzNWv9q3CG0+jGrxh6ajUtnJGpvbyvV hdEQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:from:subject:message-id:mime-version:date :dkim-signature; bh=To2+IGODACfnwpoIhBKQmVc3cqLwsoSI0sFi4wzSM/E=; b=M5R9Q3bjBIRL0amlKo5gHqMQLdMQPmNbDx6x9zMvucYUs2drFXkJzYocxcoI2E1lEy tf00fSheoK9GyahBFKF6vLLEkLZVhfLoPwykJ2BZF3fOmkiTNf3V5fe8Jo+mPVYAQru/ iFG3cjJIoTuxHr56rCHa6Ex9jCU30kSJwK+yRm6FRAyul/2AC1tAYo+DTImvKoT2Jtnn Sj75tvs+h590oW+tCZBat2Ces/Z7FwyW9G1m5i2H895D8SEnxyMV+chsgl56b9HjwyQt Q83r/kXe7D8rDDCEeeyWUYL2/XtVO0bdikExi1MIl9XBek8bJUfkeIWzscl+RKd9XPEB M5fw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20210112 header.b=cVvowtY9; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id qf36-20020a1709077f2400b007c0aa685133si3631416ejc.34.2022.12.01.11.57.34; Thu, 01 Dec 2022 11:57:53 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@google.com header.s=20210112 header.b=cVvowtY9; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229913AbiLAT0y (ORCPT + 82 others); Thu, 1 Dec 2022 14:26:54 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:47206 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229708AbiLAT0w (ORCPT ); Thu, 1 Dec 2022 14:26:52 -0500 Received: from mail-yw1-x1149.google.com (mail-yw1-x1149.google.com [IPv6:2607:f8b0:4864:20::1149]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 74564BE6B6 for ; Thu, 1 Dec 2022 11:26:51 -0800 (PST) Received: by mail-yw1-x1149.google.com with SMTP id 00721157ae682-3ceb4c331faso25673857b3.2 for ; Thu, 01 Dec 2022 11:26:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=cc:to:from:subject:message-id:mime-version:date:from:to:cc:subject :date:message-id:reply-to; bh=To2+IGODACfnwpoIhBKQmVc3cqLwsoSI0sFi4wzSM/E=; b=cVvowtY9KFRmZF7PH4+F1K/Shm+oki/xR+2GSZqQWfdCij57G18sh4Q3wsLyD7vryQ UD2OTKDBwavXQ1NaIhhGzF+ZgNiGZEAvaBFxq+jlWImzwsZ4jFpg+JSsvFL73t40cHlC cgmhGJEL0MSyv9ymPRgJeoD2Ib//Pg4LqhThq9AyoGMzOR9VWnzXPYzqJDLYAD/XhRmR 3i3iK7rgzY08A4jYM+xtgrPdoi4dAtpBEsY0GuxhBzXZVFQ30EIjfsryvNzL3ax/JXEk KYBakWKOz4NbtIa7ny0p150Kb33uWc9VybGu6bmaFOsU/H1ofJWvPQQ0wozx1LjBkMxo BhaQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:from:subject:message-id:mime-version:date:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=To2+IGODACfnwpoIhBKQmVc3cqLwsoSI0sFi4wzSM/E=; b=hTVgEvy9KjLC2Vs4PGYLIy22pVQhq+N1EXWFZEkr227Ckq/XvnyBVXoMuhbg29EQFu 9kn6DI6DuMKmHbSKxrCRxqPEuwF6VRLhFVD/P3SY0vGH8D8Ov5QkN+zxoOL+MTM0OjV2 2i0l+e4TTExNvqfLASndMN2y1T9mS6NVJnGEkSd4YszHVjSD6SPuUqr12Y0IGMBjg5i7 YzFsjUWa25kfKDW6awKKyecarrD4sh83DGSto6jFOCHn7W+U2OP0vkLRggP6Adkv/zQk XnIZcUFFr0ptDaWcDWc3xZ/lrwO2VMJ3s6BYJrRah08rRofBxLkk2CAL4jXr7Ts2tTdn MMQw== X-Gm-Message-State: ANoB5pkPuMtk6Gi2RYly6S+0QAjqw9lKjH21NqP4TZf8fvTRX9t/BXS3 T0dWoSKr/fSDn4nS1j026yo1XYfe2Pt/UNDnU89H X-Received: from ajr0.svl.corp.google.com ([2620:15c:2d4:203:3f93:cb91:7d11:def]) (user=axelrasmussen job=sendgmr) by 2002:a25:838c:0:b0:6f8:e7ca:f0ab with SMTP id t12-20020a25838c000000b006f8e7caf0abmr14229160ybk.315.1669922810753; Thu, 01 Dec 2022 11:26:50 -0800 (PST) Date: Thu, 1 Dec 2022 11:26:44 -0800 Mime-Version: 1.0 X-Mailer: git-send-email 2.39.0.rc0.267.gcb52ba06e7-goog Message-ID: <20221201192644.1941049-1-axelrasmussen@google.com> Subject: [PATCH] mm: multi-gen LRU: fix LRU size accounting on folio removal From: Axel Rasmussen To: Andrew Morton , Suleiman Souhlal , Steven Barrett , Yu Zhao , Oleksandr Natalenko , Suren Baghdasaryan , Arnd Bergmann , Peter Xu , Gaosheng Cui , Hugh Dickins , Brian Geffon , "Jan Alexander Steffens (heftig)" Cc: linux-kernel@vger.kernel.org, Yosry Ahmed , Axel Rasmussen Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-9.6 required=5.0 tests=BAYES_00,DKIMWL_WL_MED, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_NONE, SPF_HELO_NONE,SPF_PASS,USER_IN_DEF_DKIM_WL autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org When removing a folio from MGLRU, we want to update the LRU size accordingly based on the generation it belonged to previously - lru_gen_update_size() does this. The bug here is, set_mask_bits effectively clears the generation bits. Ignoring the complexity set_mask_bits is meant to handle, the code being changed here is in effect: flags = !reclaiming && lru_gen_is_active(lruvec, gen) ? BIT(PG_active) : 0; flags = *folio->flags = (*folio->flags & ~LRU_GEN_MASK) | flags; gen = ((flags & LRU_GEN_MASK) >> LRU_GEN_PGOFF) - 1; In other words, the bug is we clear all of the `LGU_GEN_MASK` bits, and then we recalculate `gen` - but of course after clearing the bits `flags & LRU_GEN_MASK` is always zero, and so now `gen` is always -1. So we effectively always call: lru_gen_update_size(lruvec, folio, -1, -1); This leads `lru_gen_update_size` to incorrectly conclude that we're **adding**, not removing, a folio. We take this path: /* addition */ if (old_gen < 0) { /* always false, new_gen is -1 too */ if (lru_gen_is_active(lruvec, new_gen)) /* ... */ __update_lru_size(lruvec, lru, zone, delta); return; } In other words, when removing, we incorrectly *add* the delta to the inactive LRU instead of subtracting. The fix is simple. We already have the generation number the folio belonged to: we set `int gen = folio_lru_gen(folio);` at the top of `lru_gen_del_folio`. So, just delete the line incorrectly recalculating the generation number. Fixes: ec1c86b25f4b ("mm: multi-gen LRU: groundwork") Signed-off-by: Axel Rasmussen --- include/linux/mm_inline.h | 1 - 1 file changed, 1 deletion(-) diff --git a/include/linux/mm_inline.h b/include/linux/mm_inline.h index e8ed225d8f7c..5bba6e0b0840 100644 --- a/include/linux/mm_inline.h +++ b/include/linux/mm_inline.h @@ -277,7 +277,6 @@ static inline bool lru_gen_del_folio(struct lruvec *lruvec, struct folio *folio, /* for folio_migrate_flags() */ flags = !reclaiming && lru_gen_is_active(lruvec, gen) ? BIT(PG_active) : 0; flags = set_mask_bits(&folio->flags, LRU_GEN_MASK, flags); - gen = ((flags & LRU_GEN_MASK) >> LRU_GEN_PGOFF) - 1; lru_gen_update_size(lruvec, folio, gen, -1); list_del(&folio->lru); -- 2.39.0.rc0.267.gcb52ba06e7-goog