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 CBEABC636D6 for ; Thu, 23 Feb 2023 17:43:36 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 5DC916B0071; Thu, 23 Feb 2023 12:43:36 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 58C776B0072; Thu, 23 Feb 2023 12:43:36 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 453FA6B0073; Thu, 23 Feb 2023 12:43:36 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0016.hostedemail.com [216.40.44.16]) by kanga.kvack.org (Postfix) with ESMTP id 368166B0071 for ; Thu, 23 Feb 2023 12:43:36 -0500 (EST) Received: from smtpin18.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id 10A2D140524 for ; Thu, 23 Feb 2023 17:43:36 +0000 (UTC) X-FDA: 80499278832.18.B5E2155 Received: from mail-pg1-f201.google.com (mail-pg1-f201.google.com [209.85.215.201]) by imf24.hostedemail.com (Postfix) with ESMTP id 4CEC1180002 for ; Thu, 23 Feb 2023 17:43:34 +0000 (UTC) Authentication-Results: imf24.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b=GnEFv8ZY; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf24.hostedemail.com: domain of 3xKX3YwYKCBUDzv84x19916z.x97638FI-775Gvx5.9C1@flex--seanjc.bounces.google.com designates 209.85.215.201 as permitted sender) smtp.mailfrom=3xKX3YwYKCBUDzv84x19916z.x97638FI-775Gvx5.9C1@flex--seanjc.bounces.google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1677174214; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=uEW2x7lvcZVgNquM9X5miuc098m/bUXcKiqyROdfsvA=; b=TUjm3cf7biSuGI4FBqJiuJlEA87tjnK0bymjxJdWtjBW38e1sXtw6UvVqI6J1k/92EfoU9 CV6XZo43F7Wt5nvy6a3R7LHKHREIlAHJ/LUgJb04QlmqZ0TLL2oPmdp/zu+lS1uVJMJvCm ZRA/0gJpUmJtnW/Gmpe40u5nIk9o87A= ARC-Authentication-Results: i=1; imf24.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b=GnEFv8ZY; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf24.hostedemail.com: domain of 3xKX3YwYKCBUDzv84x19916z.x97638FI-775Gvx5.9C1@flex--seanjc.bounces.google.com designates 209.85.215.201 as permitted sender) smtp.mailfrom=3xKX3YwYKCBUDzv84x19916z.x97638FI-775Gvx5.9C1@flex--seanjc.bounces.google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1677174214; a=rsa-sha256; cv=none; b=V8w8nukoo2Hj7JVgMDCJBYB/r9ph37xhbuTADcrSoDItk2PjyOE0Mg3nlUpWvk7+LG16TT nuk71+IOY36eBz/H/VwxbL+iIFInHJ6K/yDDGDaT3x/PUy6fewylG+L25jsaJu1yPDkpMY MLnHaeZu1ziH5uUgXPzPJeeghvdjRdE= Received: by mail-pg1-f201.google.com with SMTP id n11-20020a63e04b000000b004fac0fa0f9eso4333825pgj.19 for ; Thu, 23 Feb 2023 09:43:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=cc:to:from:subject:message-id:references:mime-version:in-reply-to :date:from:to:cc:subject:date:message-id:reply-to; bh=uEW2x7lvcZVgNquM9X5miuc098m/bUXcKiqyROdfsvA=; b=GnEFv8ZYEKJq2FLsbqFXmOIsxOoE4EVShbkz1ukBp++CxWl81cjyx0bklp6nXH3I70 1Dn7JrVCVuKLElNcGdQ1U6YXznFPEHlKh91jnsTXumsHU8puSiTvyoKnzjCVZbQPKnWS QXdxzapoB+4T797LXxDe2I0aHK2NBTy6Rw4ivHdiib/6jaI04ABl+Dtf1ReAAkKNrGSl 8NHnqSqy6ru6z4leh6bzy1EQMm6tgE5IBBFzAYn+bp+FpfKImc6YedR1CZMkmMlPEp36 c2HXP4yjSNThuM60YRVKyVgt+SlF71LlRuX35DyTXLuiC4Od9uaQKbklKgKjNGtAO3hZ O4sA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:from:subject:message-id:references:mime-version:in-reply-to :date:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=uEW2x7lvcZVgNquM9X5miuc098m/bUXcKiqyROdfsvA=; b=OYyzI4v5SuiyYiTn6UevBcdM7QAJWdox7pA42LNlmqdeMdX/pA5Qzf1X/rZQBNZmZy VBsXxdiwtMUWkZ1hO/OgW/a/bxRtvKtf/gMDTy9WjK+chePbTw5BmEbR6VF2NhIlQZNi cG05GMDcvTnqb8TATbnRkBZBWzBXAETXb5f2sCtCwzkGcGTEaqFxQmJSf555mWKEvKpe S4hIRk66Q2TCwnaS3TXlAH9LuNYJ2QnvdkdJFSr5DYViQtp96MLaJIwyhTun/6AJ3Rj7 gdVxwdTGgOnFFiOFOPfLp4JrNDB/xstoyHi7ib2UDkCzE0xKybmIXoZH05vPBD8hFsgd 5rsQ== X-Gm-Message-State: AO0yUKU9z+cPWyS8eDI4q2nVFFS8IoPnuJChdkwXKPiQKSE3IPxmAayi 6IpeFP/OHhncPw29wQIemD/HfDNTwRo= X-Google-Smtp-Source: AK7set83+Pnlpt5peCqIhQBtdMvaXZZfXzsbtxsBRoLRt6jnUdFR+O/gyNEyxZMgKJ7oNYHyvpri8MhadHU= X-Received: from zagreus.c.googlers.com ([fda3:e722:ac3:cc00:7f:e700:c0a8:5c37]) (user=seanjc job=sendgmr) by 2002:a65:6944:0:b0:4fd:2170:b2da with SMTP id w4-20020a656944000000b004fd2170b2damr1506614pgq.0.1677174212817; Thu, 23 Feb 2023 09:43:32 -0800 (PST) Date: Thu, 23 Feb 2023 09:43:31 -0800 In-Reply-To: <20230217041230.2417228-6-yuzhao@google.com> Mime-Version: 1.0 References: <20230217041230.2417228-1-yuzhao@google.com> <20230217041230.2417228-6-yuzhao@google.com> Message-ID: Subject: Re: [PATCH mm-unstable v1 5/5] mm: multi-gen LRU: use mmu_notifier_test_clear_young() From: Sean Christopherson To: Yu Zhao Cc: Andrew Morton , Paolo Bonzini , Jonathan Corbet , Michael Larabel , kvmarm@lists.linux.dev, kvm@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org, linuxppc-dev@lists.ozlabs.org, x86@kernel.org, linux-mm@google.com Content-Type: text/plain; charset="us-ascii" X-Rspamd-Queue-Id: 4CEC1180002 X-Rspamd-Server: rspam09 X-Rspam-User: X-Stat-Signature: izri1zryqdn896c6zuyuz8ky6edgc7ug X-HE-Tag: 1677174214-550493 X-HE-Meta: U2FsdGVkX1/LqHyqcVEwtems0ifs7EUOkpH8UWgFcHfUESkrks+4qI9xKg05MI1ujM9nD5TqrzQSr0g89Qnz0c4hJ61hISpJMQ3ZZUvT6uO5m7dQDc1KFx8oM50vL/rXxnHhbKFJO4mLlxR7wmMFDmixmTi5rqbbgDLjy2YpHTvdsWlFnSiYJBVs15vPkf4l3yiaE1Y2lrlQ3yv8rMhOwzW5c4Vj2Q+J0APdYTfQnYbuZ5rmwqO6IQXuBAODLDUZbFsT8x0Fr8vjl2tCbgNK9CGXv0lMy4Z9C6M/i8Jgxnj24xFLlwmx0lUGSzZcyZXWYdAUNYtLh0uh/dfE0wfuMmDzFrLNS7bUeKkeS9qS3cJeoe41+BZhhf2sUxsw/5r9iJ/zkTr20vQje0mkWpfxecuv58JfN4fb+zaufp34M5Wf/qyCgebUXmf/M0zAx4rJHVmb+tdBA1/vlalyptnQvwTUCgpDMbPXuUEqK3p8tt3hXcVTXVjWAlZ9ZW6mL7O3Mn1vDIV5gJOcAJcoDOBh3ZZo9J3jLI0WjC+JF1Rn5hMjxMjV1+8HsI5vCRG8/ivhLiXQtSYa66HFZNn0rCIZntxJCA+sw4EW+V30Zw7bAO7G2CTUQyfkOXGFTzvbLxViDO7bY0YzpMcEP1fngDd0Su3GTBpW0DOtdx6n77NNlrjLBbjvrR6mwqaDnTBFWLlzNCpCkpw7+nw/02dXHIxuQOVyyhXz16qsnAfkfvR5RkTe28+9Q55Guo12oJ//ONqsst/I4LlQsbkOn52PRrxsrxy+P/v8ZAEo/Ew61YD8juiTf/Av41Vb/wygOI6TyzOKSKASP1MUldbv8B9BIhy32HUiVAuZ7z0AIOKpunxvm4hz+GQhh+mymXqtqnFAiK/2DAKzlarAzgS5Xf47gyGFSRNxXGPGATAepUU8dT5wngeBi9q2/HsOoGm8lOi+3ti8KmVx8VZhSBPFeKlTeBM ct2zcu5R 8YTnVOYnpSFF7AG9ySi95Yv+YYiL6T1ms6HmGahk/AlLp27bXJ+mg+2D673XqkHaL+7DSjvhCqS6LvYP0ZCzT4CQpFxMzGoWIV2/YNa4tkpG2jPaKGM+toPLFwK/IKzKFP2p1g2PwlchOiXsiQAn6HEaD93KiQ70nnPaD3TJJJRn0pQmy8RD6rwQdceU+xIQm54O9iOA4l9r2wEqfc8vCpFr69cvQFQeRqCyFlmxR7tUus0L5NZO9R7fhuAO22s7wqLuvut4CgjlOsIlokSsYJ2FXAafhv9IM5HNM8LuOCIYoXqGvrZZiCm3s2M5XqzLTrP27iPssNhhOjNcnoyoPz7eG6b1QBPqSovcb9Mmh/3N0NXAnmOAtEw+WIYBv08psIOlWoq2J1uEvQsB+6oUIaqkXZwSbOD1g/xOABhfEHYUuOC/v/GpBSEXA0DBaxx7zoad5bLI0nfUGsspCmDvo+TRlVUzXcWg0Wkkc/qY34yBIg+ELHDnM0FPog+lVGyoWPNsLP9e71RJeg7/z25FeYj2xdl1EvY8rSeicbxiV3eLOyTR/09uUVO1h+uMLwVFeJF1isPY4jIe9S0GQDr/MIKgM/2MRITZrmHAQmv6/SKX2lKZQbHxmDp4gEwarW16i71Psn90oEvOzrPuleJvhq9YWGA== 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: On Thu, Feb 16, 2023, Yu Zhao wrote: > An existing selftest can quickly demonstrate the effectiveness of this > patch. On a generic workstation equipped with 128 CPUs and 256GB DRAM: Not my area of maintenance, but a non-existent changelog (for all intents and purposes) for a change of this size and complexity is not acceptable. > $ sudo max_guest_memory_test -c 64 -m 250 -s 250 > > MGLRU run2 > --------------- > Before ~600s > After ~50s > Off ~250s > > kswapd (MGLRU before) > 100.00% balance_pgdat > 100.00% shrink_node > 100.00% shrink_one > 99.97% try_to_shrink_lruvec > 99.06% evict_folios > 97.41% shrink_folio_list > 31.33% folio_referenced > 31.06% rmap_walk_file > 30.89% folio_referenced_one > 20.83% __mmu_notifier_clear_flush_young > 20.54% kvm_mmu_notifier_clear_flush_young > => 19.34% _raw_write_lock > > kswapd (MGLRU after) > 100.00% balance_pgdat > 100.00% shrink_node > 100.00% shrink_one > 99.97% try_to_shrink_lruvec > 99.51% evict_folios > 71.70% shrink_folio_list > 7.08% folio_referenced > 6.78% rmap_walk_file > 6.72% folio_referenced_one > 5.60% lru_gen_look_around > => 1.53% __mmu_notifier_test_clear_young Do you happen to know how much of the improvement is due to batching, and how much is due to using a walkless walk? > @@ -5699,6 +5797,9 @@ static ssize_t show_enabled(struct kobject *kobj, struct kobj_attribute *attr, c > if (arch_has_hw_nonleaf_pmd_young() && get_cap(LRU_GEN_NONLEAF_YOUNG)) > caps |= BIT(LRU_GEN_NONLEAF_YOUNG); > > + if (kvm_arch_has_test_clear_young() && get_cap(LRU_GEN_SPTE_WALK)) > + caps |= BIT(LRU_GEN_SPTE_WALK); As alluded to in patch 1, unless batching the walks even if KVM does _not_ support a lockless walk is somehow _worse_ than using the existing mmu_notifier_clear_flush_young(), I think batching the calls should be conditional only on LRU_GEN_SPTE_WALK. Or if we want to avoid batching when there are no mmu_notifier listeners, probe mmu_notifiers. But don't call into KVM directly.