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 99040C433EF for ; Fri, 13 May 2022 15:50:22 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id D3CC76B0073; Fri, 13 May 2022 11:50:21 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id CEC7C8D0002; Fri, 13 May 2022 11:50:21 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id B8DE48D0001; Fri, 13 May 2022 11:50:21 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id A43266B0073 for ; Fri, 13 May 2022 11:50:21 -0400 (EDT) Received: from smtpin01.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id 86CA8215AA for ; Fri, 13 May 2022 15:50:21 +0000 (UTC) X-FDA: 79461156642.01.644CEEA Received: from mail-qv1-f46.google.com (mail-qv1-f46.google.com [209.85.219.46]) by imf23.hostedemail.com (Postfix) with ESMTP id 7970A1400B1 for ; Fri, 13 May 2022 15:50:05 +0000 (UTC) Received: by mail-qv1-f46.google.com with SMTP id js14so6926843qvb.12 for ; Fri, 13 May 2022 08:50:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cmpxchg-org.20210112.gappssmtp.com; s=20210112; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=Kye4TfWEBKeNkvsN1Z8PpM0cIuVevPyfJP2pQ+b2OJ0=; b=ZZ/JJCRDz3yE4ILSty048bcbPErmsDUK3HlgCxPZevGvO0s7lKzzyxYdFDw1dJf9ph MIp+dwz/aXhjTfmLJaPj/lFR5KENnPsRIaVfRdKCuXnMx6qMaG0uPs9glvL+IiheyQV+ I8N0k1bffzWgc5Xm+tBeTXdy8CbQJfgCaMsHgTm1sfLVt/+VGnsbnrEpzH2RKA967Lgp i0c6ZYtdpmtmfZZuTg2GnWU+ABJlGS07aIDJN1CLeOQkEF/JyGUWyE+RbOazEYEr/CaR 3SpCLEHRQ4pi9gjxDfMWcHE6xNgzt5GERI+gy2A1oDXWEszhLZUV5HDLMnSPDj/P5+Pq xL0Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=Kye4TfWEBKeNkvsN1Z8PpM0cIuVevPyfJP2pQ+b2OJ0=; b=MtHCY7W7XbcLWplPSWpx8AGishurA4U7lqUYhJ/0skv5Y5GkwymLpvwPTFF/NQaBZ5 w3l+FJ6fL6+iOkw7HOs9DDyUhxiaDFPDj//Ciyfn6LH1Ne1FTccY4yL6quXMbNXN6qC7 2sfUiYsGK75DREUxdyfA8r+1ArHxgKspeptxCh+ZMp8A67/1mIxA6kwFK9h0yMZs2n8m a8uBOd87hBmstwxfZrXGilYgDwWz4gOD8T5oaHQxkr9zLOzFNHRRw0BEkJPCU7zcieDt uCO89INAzbZ16y58pCDwV+vVt2HmbDuU1trCOue2ju0nsTHI2QtqnSmtYjFLVqsoewl/ Vlpw== X-Gm-Message-State: AOAM531V4gs55gSva08+LKk+YzEmo0uXpseb0dZpR2e1F2zR0yuWYNo3 UoLiuAa6Kz9eBKgwlJVFVtWR+Q== X-Google-Smtp-Source: ABdhPJyktZGo/sFqunY+AGQMbzOIwUczaPGJ0N+6rs6ilDbZkXUx75C2yJo+GV2MPE1GxzwaNcDQ8A== X-Received: by 2002:a05:6214:401a:b0:459:5a57:ba6f with SMTP id kd26-20020a056214401a00b004595a57ba6fmr4923590qvb.96.1652457019420; Fri, 13 May 2022 08:50:19 -0700 (PDT) Received: from localhost ([2620:10d:c091:480::1:14fe]) by smtp.gmail.com with ESMTPSA id f6-20020a05622a114600b002f39b99f69esm1622685qty.56.2022.05.13.08.50.18 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 13 May 2022 08:50:18 -0700 (PDT) Date: Fri, 13 May 2022 11:50:18 -0400 From: Johannes Weiner To: Sean Christopherson Cc: Yosry Ahmed , Marc Zyngier , Tejun Heo , Zefan Li , 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 , cgroups@vger.kernel.org, Linux Kernel Mailing List , linux-arm-kernel@lists.infradead.org, kvmarm@lists.cs.columbia.edu, kvm@vger.kernel.org, Linux-MM Subject: Re: [PATCH v4 1/4] mm: add NR_SECONDARY_PAGETABLE to count secondary page table uses. Message-ID: References: <20220429201131.3397875-1-yosryahmed@google.com> <20220429201131.3397875-2-yosryahmed@google.com> <87ilqoi77b.wl-maz@kernel.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Stat-Signature: tycjihh5rhq117h84zzqiuw3db44dk3u X-Rspamd-Server: rspam12 X-Rspamd-Queue-Id: 7970A1400B1 Authentication-Results: imf23.hostedemail.com; dkim=pass header.d=cmpxchg-org.20210112.gappssmtp.com header.s=20210112 header.b="ZZ/JJCRD"; spf=pass (imf23.hostedemail.com: domain of hannes@cmpxchg.org designates 209.85.219.46 as permitted sender) smtp.mailfrom=hannes@cmpxchg.org; dmarc=pass (policy=none) header.from=cmpxchg.org X-Rspam-User: X-HE-Tag: 1652457005-279887 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, May 12, 2022 at 11:29:38PM +0000, Sean Christopherson wrote: > On Thu, May 12, 2022, Johannes Weiner wrote: > > On Mon, May 02, 2022 at 11:46:26AM -0700, Yosry Ahmed wrote: > > > On Mon, May 2, 2022 at 3:01 AM Marc Zyngier wrote: > > > > What do you plan to do for IOMMU page tables? After all, they serve > > > > the exact same purpose, and I'd expect these to be handled the same > > > > way (i.e. why is this KVM specific?). > > > > > > The reason this was named NR_SECONDARY_PAGTABLE instead of > > > NR_KVM_PAGETABLE is exactly that. To leave room to incrementally > > > account other types of secondary page tables to this stat. It is just > > > that we are currently interested in the KVM MMU usage. > > > > Do you actually care at the supervisor level that this memory is used > > for guest page tables? > > Hmm, yes? KVM does have a decent number of large-ish allocations that aren't > for page tables, but except for page tables, the number/size of those allocations > scales linearly with either the number of vCPUs or the amount of memory assigned > to the VM (with no room for improvement barring KVM changes). > > Off the top of my head, KVM's secondary page tables are the only allocations that > don't scale linearly, especially when nested virtualization is in use. Thanks, that's useful information. Are these other allocations accounted somewhere? If not, are they potential containment holes that will need fixing eventually? > > It seems to me you primarily care that it is reported *somewhere* > > (hence the piggybacking off of NR_PAGETABLE at first). And whether > > it's page tables or iommu tables or whatever else allocated for the > > purpose of virtualization, it doesn't make much of a difference to the > > host/cgroup that is tracking it, right? > > > > (The proximity to nr_pagetable could also be confusing. A high page > > table count can be a hint to userspace to enable THP. It seems > > actionable in a different way than a high number of kvm page tables or > > iommu page tables.) > > I don't know about iommu page tables, but on the KVM side a high count can also > be a good signal that enabling THP would be beneficial. Well, maybe. It might help, but ultimately it's the process that's in control in all cases: it's unmovable kernel memory allocated to manage virtual address space inside the task. So I'm still a bit at a loss whether these things should all be lumped in together or kept separately. meminfo and memory.stat are permanent ABI, so we should try to establish in advance whether the new itme is really a first-class consumer or part of something bigger. The patch initially piggybacked on NR_PAGETABLE. I found an email of you asking why it couldn't be a separate item, but it didn't provide a reasoning for that decision. Could you share your thoughts on that? Thanks