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 C5F3EC00140 for ; Mon, 15 Aug 2022 15:14:33 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229994AbiHOPOb (ORCPT ); Mon, 15 Aug 2022 11:14:31 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:53840 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S240234AbiHOPOQ (ORCPT ); Mon, 15 Aug 2022 11:14:16 -0400 Received: from mail-qv1-xf2d.google.com (mail-qv1-xf2d.google.com [IPv6:2607:f8b0:4864:20::f2d]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 7C165275D8 for ; Mon, 15 Aug 2022 08:13:54 -0700 (PDT) Received: by mail-qv1-xf2d.google.com with SMTP id mn10so797413qvb.10 for ; Mon, 15 Aug 2022 08:13:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cmpxchg-org.20210112.gappssmtp.com; s=20210112; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc; bh=SVpUVzPm5W0Voyj60yN9H262DjM/0dmmT6CafgD5LQQ=; b=gOOWpTPZwiM17WF4f5gKOhDCSLU9Xa7Ddw5htxLmCf1V9e6337lrTGD7E89v0QfRVJ UKtYdBjRPV+SoEPNaViOMhRD3539K1N9epXUdaYog0Ghqr9Hz/q4svAJMLG3UwT6sWxo +VuEzH2WqgtjnVrw0RSEk1ZZzuVg1Iu9u/y7a/XQdVWZSk6nHZ6e0lHT1onclU+0r7hJ Q5W7083KTKmB0O6AdzaftKfJMa8rGq92lENKSy6Nq4zRtkJGrMxpmyvJ4DecH3ziV2yY aiceCwnsy9e7wohTT0MQGWEDNlpX9jUl/3N9hIGAEaDitMSoD3owjEMqWgSnWOXKWzKG oZdg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc; bh=SVpUVzPm5W0Voyj60yN9H262DjM/0dmmT6CafgD5LQQ=; b=g7nmYWb6qzxC8JYJ0fYtGXLbWrvBIhNQXgzcU1ISc3NxgXioimhF7e+GARakGme/K1 K9WfG7euKJtemr1JfM4IS6PWtNA0NQLXdWtaWx5t2oNXm9J9xpLWUbfnv1hokKoCPT61 7JuzK2G9FUx+xUaA6rtdCefELWYOeJ8urgCOemCav51+hxzP+d4mkctLodnFindjhHDW R94K+TPYVbwGK7dG1FmMBHcZIswf8fAwshnY2AJqlGnyywJu4G18xaQ28wlY7BmLCYso Gdti96xGGOV4JWgAU50hz2dIKR0lCwi5X7dMGwb9R0QSi9jvnW2F+gOVIyd0y0i1V7zK qopQ== X-Gm-Message-State: ACgBeo1cVL5gvQ9favOwprfP9/l4ux2I2IiGUJf4i6OusW1PImwIHto3 mIcH3QcD+IHN6hbSPB5uUWedIg== X-Google-Smtp-Source: AA6agR5vrCQlXB1uSwNPvBPyKCFf9sAWMWRn04guCYRZ/JGYECdgQAzs4QjOMDL0tMgKmgpjwr5NJQ== X-Received: by 2002:a0c:b2c5:0:b0:47e:4f8e:f0ae with SMTP id d5-20020a0cb2c5000000b0047e4f8ef0aemr13992515qvf.9.1660576433584; Mon, 15 Aug 2022 08:13:53 -0700 (PDT) Received: from localhost ([2620:10d:c091:480::a23e]) by smtp.gmail.com with ESMTPSA id r5-20020ac87945000000b0031f0485aee0sm2014653qtt.88.2022.08.15.08.13.52 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 15 Aug 2022 08:13:52 -0700 (PDT) Date: Mon, 15 Aug 2022 11:13:51 -0400 From: Johannes Weiner To: Yosry Ahmed Cc: Sean Christopherson , Tejun Heo , Zefan Li , Marc Zyngier , James Morse , Alexandru Elisei , Suzuki K Poulose , Paolo Bonzini , Vitaly Kuznetsov , Wanpeng Li , Jim Mattson , Joerg Roedel , Andrew Morton , Michal Hocko , Roman Gushchin , Shakeel Butt , Oliver Upton , Huang@google.com, Shaoqin , Cgroups , Linux Kernel Mailing List , linux-arm-kernel@lists.infradead.org, kvmarm@lists.cs.columbia.edu, kvm@vger.kernel.org, Linux-MM Subject: Re: [PATCH v6 1/4] mm: add NR_SECONDARY_PAGETABLE to count secondary page table uses. Message-ID: References: <20220628220938.3657876-1-yosryahmed@google.com> <20220628220938.3657876-2-yosryahmed@google.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Aug 08, 2022 at 01:06:15PM -0700, Yosry Ahmed wrote: > On Mon, Jul 18, 2022 at 11:26 AM Yosry Ahmed wrote: > > > > On Tue, Jul 12, 2022 at 4:06 PM Sean Christopherson wrote: > > > > > > On Tue, Jul 12, 2022, Yosry Ahmed wrote: > > > > Thanks for taking another look at this! > > > > > > > > On Thu, Jul 7, 2022 at 1:59 PM Sean Christopherson wrote: > > > > > > > > > > On Tue, Jun 28, 2022, Yosry Ahmed wrote: > > > > > > diff --git a/include/linux/mmzone.h b/include/linux/mmzone.h > > > > > > index aab70355d64f3..13190d298c986 100644 > > > > > > --- a/include/linux/mmzone.h > > > > > > +++ b/include/linux/mmzone.h > > > > > > @@ -216,6 +216,7 @@ enum node_stat_item { > > > > > > NR_KERNEL_SCS_KB, /* measured in KiB */ > > > > > > #endif > > > > > > NR_PAGETABLE, /* used for pagetables */ > > > > > > + NR_SECONDARY_PAGETABLE, /* secondary pagetables, e.g. kvm shadow pagetables */ > > > > > > > > > > Nit, s/kvm/KVM, and drop the "shadow", which might be misinterpreted as saying KVM > > > > > pagetables are only accounted when KVM is using shadow paging. KVM's usage of "shadow" > > > > > is messy, so I totally understand why you included it, but in this case it's unnecessary > > > > > and potentially confusing. > > > > > > > > > > And finally, something that's not a nit. Should this be wrapped with CONFIG_KVM > > > > > (using IS_ENABLED() because KVM can be built as a module)? That could be removed > > > > > if another non-KVM secondary MMU user comes along, but until then, #ifdeffery for > > > > > stats the depend on a single feature seems to be the status quo for this code. > > > > > > > > > > > > > I will #ifdef the stat, but I will emphasize in the docs that is > > > > currently *only* used for KVM so that it makes sense if users without > > > > KVM don't see the stat at all. I will also remove the stat from > > > > show_free_areas() in mm/page_alloc.c as it seems like none of the > > > > #ifdefed stats show up there. > > > > > > It's might be worth getting someone from mm/ to weigh in before going through the > > > trouble, my suggestion/question is based purely on the existing code. > > > > Any mm folks with an opinion about this? > > > > Any preference on whether we should wrap NR_SECONDARY_PAGETABLE stats > > with #ifdef CONFIG_KVM for now as it is currently the only source for > > this stat? > > Any input here? > > Johannes, you have been involved in discussions in earlier versions of > this series, any thoughts here? No super strong feelings here. Most major distros have CONFIG_KVM=y/n, so it'll be a common fixture anyway, and the ifdef is proooobably not worth it for hiding it from people. OTOH, the ifdef is useful for documenting the code. If you've already ifdeffed it now, I'd say go ahead with it. Otherwise, don't :) My 2c.