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 CB9A5C48BF6 for ; Thu, 22 Feb 2024 00:21:57 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 6157D6B0082; Wed, 21 Feb 2024 19:21:57 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 5C6126B0083; Wed, 21 Feb 2024 19:21:57 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 466CC6B0085; Wed, 21 Feb 2024 19:21:57 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0010.hostedemail.com [216.40.44.10]) by kanga.kvack.org (Postfix) with ESMTP id 362ED6B0082 for ; Wed, 21 Feb 2024 19:21:57 -0500 (EST) Received: from smtpin20.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id 01799140BCB for ; Thu, 22 Feb 2024 00:21:56 +0000 (UTC) X-FDA: 81817537074.20.2808F57 Received: from mail-qv1-f41.google.com (mail-qv1-f41.google.com [209.85.219.41]) by imf11.hostedemail.com (Postfix) with ESMTP id 0F86A40015 for ; Thu, 22 Feb 2024 00:21:54 +0000 (UTC) Authentication-Results: imf11.hostedemail.com; dkim=pass header.d=ziepe.ca header.s=google header.b=HyZgZF4f; spf=pass (imf11.hostedemail.com: domain of jgg@ziepe.ca designates 209.85.219.41 as permitted sender) smtp.mailfrom=jgg@ziepe.ca; dmarc=none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1708561315; 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:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=9rn4mWdOER6tRcIB1iLpkedD4oyQHhFAy8BqoLay5HA=; b=co548w5XTIlUBXxzdqAwvPVqTX5pNyWTfBVB06ZAFRkXhUhqHJf27usOqGD3QIiTmbV3xE TQDb3cZejGrsZY3bsqDGEetJy5Ayv970rZvhwpaJU3TNDGx8qiyn9bYpDZ6UZ2cTEkbOCI /puBqFS0xywNKHmmR/61hcv1QLzJToU= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1708561315; a=rsa-sha256; cv=none; b=Iy6RLM1rVFwtaQTpvxx3zcP5Tak8lGuMeQdS1PbHIWY0kTsrE2L5QRmymem59eMRNm7Grr uGcp7xQ0B4B2bdPrDZio7yQ7OemgB+3aMNvn9SY99DkvmP7Io/FashoWPSm6t2wZok2D+1 BTg+FDv88bjV47IcYtM0dOztMNBxBE0= ARC-Authentication-Results: i=1; imf11.hostedemail.com; dkim=pass header.d=ziepe.ca header.s=google header.b=HyZgZF4f; spf=pass (imf11.hostedemail.com: domain of jgg@ziepe.ca designates 209.85.219.41 as permitted sender) smtp.mailfrom=jgg@ziepe.ca; dmarc=none Received: by mail-qv1-f41.google.com with SMTP id 6a1803df08f44-68f54a65ae2so19145626d6.0 for ; Wed, 21 Feb 2024 16:21:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ziepe.ca; s=google; t=1708561314; x=1709166114; darn=kvack.org; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:message-id:subject:cc:to:from:date:from:to :cc:subject:date:message-id:reply-to; bh=9rn4mWdOER6tRcIB1iLpkedD4oyQHhFAy8BqoLay5HA=; b=HyZgZF4f4H9kegpfVWYG0rrn5TJ4ZQgsiOl1guYfHezBETvkt0RazfzbQ6SelWpqxo Aya4i7zoheTjqs6IoCPaompUSVX3+J51OvMFZVAgSbjuVEoVX1mFOXan0LPX//QZu0sQ nPU3G10+dD4BmrDQivlbqLNXtVQ8ixqOHTang4vhvaAx0FQKrct/keMup6oKXQMcLqJ8 zH/vvUgGAVwqfkg2Ml7fQSy9MIHsjvSqjoFYCaFCt2lla1iGijWvySqrp2YrR7clLIrH bA6tdCqt38EE8LmyXtbCVfvLL3iL6uRM9YAGFyD+HGRa7h0JJY5eveRxsbg3ZIdhjvs0 Hy1A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1708561314; x=1709166114; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:message-id:subject:cc:to:from:date :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=9rn4mWdOER6tRcIB1iLpkedD4oyQHhFAy8BqoLay5HA=; b=N+P7Ocfzcht/B3WKY1cP4JbeawDaXw+BdHTTSYFLFtKlosFvgK6i+tvRhiQeoKfReU Wh4upeyL3azrmJiEYqR/HrL8xoeEHGK9tMS6T3Ng21r5itBQimAAokiZYxV+QGCNK5za 1qTECNtN+5p7pNaUFltXGhgYcgE7UG8Vai2WqfETTS3HcJq+zW6CIJIYozJdXp+KzNDm a9HDkLv+ibGnG/Gq0s1pN92eq49+rGcgwFXSGV1MMcb+1wwu2wDwFeI70uO5z2PppN6x xIMu7Tc0MCaFeHZvmh3pc/w7P14X/Wp366NZKxU8+/bxzxRUq1/+VHrDFBPp7Pt9K5vS HxqA== X-Forwarded-Encrypted: i=1; AJvYcCXbcFW/2hdE73mL07cZKSNAPUAeM7LhweZJsW2U6EaD5P3tc4ypiu72qWy249DmiCz70q26uBpzRkJ9cB8S8ndVV2Q= X-Gm-Message-State: AOJu0YzQgjmHYXWrnvDv+RTbofNeCkw2dGs8YDOaCWM/pasVoUwoRor/ gWhjYKmDWY3QhbRGax2AHFCAeaPfzhOJZKnlG5xETiD/LdAwSeVAd836fAB2cnU= X-Google-Smtp-Source: AGHT+IGSJoZu17XCLPx2AJSIv4qmgm+x+WexJaUrwx1qRLzsVh+X4k/87Gsnxjx0m8GySXbzSbUfyw== X-Received: by 2002:ad4:5ce3:0:b0:68f:8d7c:73cd with SMTP id iv3-20020ad45ce3000000b0068f8d7c73cdmr10367841qvb.8.1708561314072; Wed, 21 Feb 2024 16:21:54 -0800 (PST) Received: from ziepe.ca (hlfxns017vw-142-68-80-239.dhcp-dynamic.fibreop.ns.bellaliant.net. [142.68.80.239]) by smtp.gmail.com with ESMTPSA id lb25-20020a056214319900b0068f9bb1a247sm1871280qvb.19.2024.02.21.16.21.53 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 21 Feb 2024 16:21:53 -0800 (PST) Received: from jgg by wakko with local (Exim 4.95) (envelope-from ) id 1rcwqW-00DQWC-Tn; Wed, 21 Feb 2024 20:21:52 -0400 Date: Wed, 21 Feb 2024 20:21:52 -0400 From: Jason Gunthorpe To: Pasha Tatashin Cc: Will Deacon , akpm@linux-foundation.org, alim.akhtar@samsung.com, alyssa@rosenzweig.io, asahi@lists.linux.dev, baolu.lu@linux.intel.com, bhelgaas@google.com, cgroups@vger.kernel.org, corbet@lwn.net, david@redhat.com, dwmw2@infradead.org, hannes@cmpxchg.org, heiko@sntech.de, iommu@lists.linux.dev, jernej.skrabec@gmail.com, jonathanh@nvidia.com, joro@8bytes.org, krzysztof.kozlowski@linaro.org, linux-doc@vger.kernel.org, linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org, linux-rockchip@lists.infradead.org, linux-samsung-soc@vger.kernel.org, linux-sunxi@lists.linux.dev, linux-tegra@vger.kernel.org, lizefan.x@bytedance.com, marcan@marcan.st, mhiramat@kernel.org, m.szyprowski@samsung.com, paulmck@kernel.org, rdunlap@infradead.org, robin.murphy@arm.com, samuel@sholland.org, suravee.suthikulpanit@amd.com, sven@svenpeter.dev, thierry.reding@gmail.com, tj@kernel.org, tomas.mudrunka@gmail.com, vdumpa@nvidia.com, wens@csie.org, yu-cheng.yu@intel.com, rientjes@google.com Subject: Re: [PATCH v3 10/10] iommu: account IOMMU allocated memory Message-ID: <20240222002152.GG13491@ziepe.ca> References: <20231226200205.562565-1-pasha.tatashin@soleen.com> <20231226200205.562565-11-pasha.tatashin@soleen.com> <20240213131210.GA28926@willie-the-truck> <20240216175752.GB2374@willie-the-truck> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-Rspamd-Queue-Id: 0F86A40015 X-Rspam-User: X-Rspamd-Server: rspam11 X-Stat-Signature: k5zy8x5gdppe6jp8iyiqy6o3eb97hroq X-HE-Tag: 1708561314-801235 X-HE-Meta: U2FsdGVkX19Yew3gsn+m7KurAWEo3iB5Jdz6AP6fmS/kcTeR0oqgoYu8h7yc4dp7i0nfBFGE1Cvy12RujFNuvTI08yKjcRP9BodHxW07tjqSZG9q2wn3ujKILg2vhFmNRnAx0sETEnV4RnIm5FT2CPZKyT0hHdRLgjJMkLsPBGj3Uv8TfxYQbFj7wk7kbLmxiBE2R4CUXIEZ3aO9Jc8P65FnWDb5ougI78EbQXyTutlQ8kNrfCh6ki8Z8YuVs9mj63TymyXiWtenpdB8bx+EbGV5XNuTg0C5NkEXUprfp4CUuzZ2ZYAADlKFqre3TZUwxIQn9c5sE4VA2+LJOzHZH2u0NsSVr942IFhh0Qv7iCNUCF9IVA968jAVFvltYm3Bg/BkAbvfLREh2kSPJQDN7RgAgxEBIbLCdBUTDTMML3s0hyuZsU7inYGObFZR+z9aDKPFoLQ5QE0gZ1UyA45MA+6M4wKHYh3ccDGSsjcYGMiwoKcOfV/jBkEHQOYUISaXdoCP9G3a55LMvPegPrtLx4PoYhgKmyPE+iQs09qdjv4xvHjdNwknkY66Usfi+Fl7ogwL29Gt/4BpyRyD4bcfRhN5yredIPluKMg9wCEAUkcCrz1vpW4ur7kOjhp7TEjCMDWv9ht4ArIobCT+0DcQkxCssqczrPf0H0XvYi0q22yhFCRprRi7R0YMUvRpWF3RZxIc8IvTperyF5cKaDeD5usfOJyi701nNy9MrI0kxqakhx09D8UkG4ciagzApzg6yAExv1vAtxe/dhtrgoiN2y2FHXERYnREW3hLLT5iVTnH4jpaGtKZXq8NspfZ2J1zfOb67+CmUl1Wk5zWBXEOVbeVtE7g0YqoiNpp4pCQQeSHfjHEbmkuxkws/AMjORXrCKM8VQu1hz0auBYtrSq37/Ham5m+76jEvc9zOHG/MfWUXHT1b12hBY3fIwurQezNRpSaumJUHkWiz9gaexa lsJV4WIo tKlG2/WVpCuAQq2prltArMoweEx543i+fGW0iktYQ6JFS53NxSlR20AAN5hsN7uUX87ukT1TS/Csox6IW8U5edGqqM1H+tiDMatP500VS95o0ctkhUnXpgF8/lyy3DoH+f5kht//hhJ2GHWwUcNATpo87t4VQyjNrJZbfyFJ14gBBU6G0QpiNqfC5EkMvytoOw9vy/ayEs077JyWHNdvuc8u0/9SblVdQrEc4xVaPcMc/6nwmbJcVNO42zYt3ZVsHaU0hShrzsexouUELL/wgBJyC/JoHCF33pTVKMR1JPNxQXg4KTFPSyx8cXKFs7LFV2/we8j7QpcHIKiQVyeqCCTDuXISvlLebSnKhnFiZ5KeXKeulQD2dmeg51Xaj0S280/0zdxgOtT6mwag5umKzOtjYAq3/0Ws1bFNNKPYzg/bHE0oFiUuVZVwk1xlcC5gahM/8kgGKE/7V3mCthwD/plB6icuZxtfGBaeO 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: List-Subscribe: List-Unsubscribe: On Fri, Feb 16, 2024 at 02:48:00PM -0500, Pasha Tatashin wrote: > On Fri, Feb 16, 2024 at 12:58 PM Will Deacon wrote: > > > > On Tue, Feb 13, 2024 at 10:44:53AM -0500, Pasha Tatashin wrote: > > > > > SecPageTables > > > > > - Memory consumed by secondary page tables, this currently > > > > > - currently includes KVM mmu allocations on x86 and arm64. > > > > > + Memory consumed by secondary page tables, this currently includes > > > > > + KVM mmu and IOMMU allocations on x86 and arm64. > > > > > > Hi Will, > > > > > > > While I can see the value in this for IOMMU mappings managed by VFIO, > > > > doesn't this end up conflating that with the normal case of DMA domains? > > > > For systems that e.g. rely on an IOMMU for functional host DMA, it seems > > > > wrong to subject that to accounting constraints. > > > > > > The accounting constraints are only applicable when GFP_KERNEL_ACCOUNT > > > is passed to the iommu mapping functions. We do that from the vfio, > > > iommufd, and vhost. Without this flag, the memory useage is reported > > > in /proc/meminfo as part of SecPageTables field, but not constrained > > > in cgroup. > > > > Thanks, Pasha, that explanation makes sense. I still find it bizarre to > > include IOMMU allocations from the DMA API in SecPageTables though, and > > I worry that it will confuse people who are using that metric as a way > > to get a feeling for how much memory is being used by KVM's secondary > > page-tables. As an extreme example, having a non-zero SecPageTables count > > without KVM even compiled in is pretty bizarre. > > I agree; I also prefer a new field in /proc/meminfo named > 'IOMMUPageTables'. This is what I proposed at LPC, but I was asked to > reuse the existing 'SecPageTables' field instead. The rationale was > that 'secondary' implies not only KVM page tables, but any other > non-regular page tables. Right, SeanC mentioned that the purpose of SecPageTables was to capture all non-mm page table radix allocations. > I would appreciate the opinion of IOMMU maintainers on this: is it > preferable to bundle the information with 'SecPageTables' or maintain > a separate field? I think you should keep them together. I don't think we should be introducing new counters, in general. Detailed memory profile should come from some kind of more dynamic and universal scheme. Hopefully that other giant thread about profiling will reach some conclusion. Jason