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 AF8B8C48BF6 for ; Wed, 21 Feb 2024 13:29:34 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 166686B0075; Wed, 21 Feb 2024 08:29:34 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 116DC6B0078; Wed, 21 Feb 2024 08:29:34 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id F20106B007B; Wed, 21 Feb 2024 08:29:33 -0500 (EST) 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 E31A16B0075 for ; Wed, 21 Feb 2024 08:29:33 -0500 (EST) Received: from smtpin15.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id 882F0160A42 for ; Wed, 21 Feb 2024 13:29:33 +0000 (UTC) X-FDA: 81815893026.15.05961A3 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by imf22.hostedemail.com (Postfix) with ESMTP id CAA81C0017 for ; Wed, 21 Feb 2024 13:29:31 +0000 (UTC) Authentication-Results: imf22.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=YiBXL6Vx; dmarc=pass (policy=none) header.from=kernel.org; spf=pass (imf22.hostedemail.com: domain of will@kernel.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=will@kernel.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1708522171; 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=XPQMUbdeJsipNQppccNsJgoq358eGqeWOGlcReR5f8M=; b=14KDyS4YSXq3xhfsM41QpfN7B7nHNnm5NNhE3psbvffoeNi/Ry6S7n66e8ZvsNoTWFudy3 ZsShhekL5Bx0U7PJAFsv49WRjwDkdBvWkDZPIUvdHYw3O9UrkTwiMxErHbt6BjPY5dyrPT 8VZwwvwWDOisRMQGBA43kEuQvGwgnQ0= ARC-Authentication-Results: i=1; imf22.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=YiBXL6Vx; dmarc=pass (policy=none) header.from=kernel.org; spf=pass (imf22.hostedemail.com: domain of will@kernel.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=will@kernel.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1708522171; a=rsa-sha256; cv=none; b=NRNBRvADn9pDa5yaLRu6O6NQPhPAjK5ocH/LdYfInxqhhifHRnxNZ8rwAX3RBnMrKnzqqL ggOa1DVh45MjiBnRTh7OyBqV8/EG2E6Zed8n0zuAwK/pUN3rs+XAPTCjfN4wMRQB51hYJq +kA8GZ3Eus84on3co1D80t5aNAdXsN8= Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by dfw.source.kernel.org (Postfix) with ESMTP id D5729614FA; Wed, 21 Feb 2024 13:29:30 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 31A34C43390; Wed, 21 Feb 2024 13:29:23 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1708522170; bh=1uXA3tuk5DSrYBKlcNHOd+IpgOiOvjcTfXfos632w+8=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=YiBXL6VxZWpc4KOcEK2JVTNsblnglRNXqfOhTGNFEOOP3Z05SEHo/yJJZgGTfy6Yy x5i2ENXsswo0PsZfBbOQAsZyHoNv/onQNmWuZpA+8n/oxElvFdoqRi0mzLwWVmnusP 4o020bDIPLnaGgwRaawuQ6ExPSxEwS9tjNHSOU3RRAgwx0t3fpNdN4N9xYYf8nH+f/ AOtHcMNsU9xJMldnzfakVY3MacOvm0l/CKsIgCAZnZ61GsXNnBfAEtA1aDxQgVd0+n jM6rpcQZPk7BVwHx5KaEP4lSa8C5hCRPVxHKvPn3uCLDMLLgfnPAlq21qZXhNA05QB jflhzGp8tFFOg== Date: Wed, 21 Feb 2024 13:29:19 +0000 From: Will Deacon To: Pasha Tatashin Cc: 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: <20240221132919.GC7273@willie-the-truck> 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: User-Agent: Mutt/1.10.1 (2018-07-13) X-Rspam-User: X-Stat-Signature: qtw53g3yojiuhu77zhsjnq4eowsq5j3j X-Rspamd-Server: rspam07 X-Rspamd-Queue-Id: CAA81C0017 X-HE-Tag: 1708522171-958471 X-HE-Meta: U2FsdGVkX19ouM1CVFli9dwDEeX7zKkXdzho7bXJB05Pk25MC3WXw82sU98JtE33am0YxAKoqFI2t3yK5PknS7ppGqD+odVFoVkjCSP6E2oqrM1biIdzCB97+lNA6yhOQ+5hBEperoo74s8hUbx+zT8Y1qjRe/aREzRfKEOOTozwkkMpXZSvkDG35p5LdP1i2RGtMs7ewAseNY9IKUeisvZjDg4bVzNRR9IfuMVDHVHJNaYpNMVavkNlRLeFQYDoYprX4sAKniSn8i9ifbtD1SWm4+zWoQ1igVObxgmAsFjmUAglAFhXKHZW6/6csu01Kf39Zzo5ZAjq2qXEM+il7lPkfWY6gObwqe+whiBDnvqq14iielodqebo2L3XNvtMHMSJ8re+zIfaZqV1duL4y9kyF0NgaGX8TRYq1rainyIU1T7qdH4Dfq1A0Y3PCgGwkUSyyd6vsqR8Xwh48k9QNklJxPl64irGzqx3MWeIsMnsrb2N+1/m1VO0PFqUxN8U4fcFcuk/M0QcIpdJkV/KtB9K3U8XvVH6R++7PN3qms4JY6AUQspIzRwilWQWthldcms/yTki+NsJhE2KwqGnDtTNl6otWqNcwavXnn3LId/7CguZU9W6bY2nZXK10zpc18tcQVT4wz6qFABYaoMXvPSangz3cDO/iM1zRjZ78Qj7xqShGTcA52UkFlAhGTZ0RO6F5s9NxdmHGkV5iBsLxOyLgRXHVAi8PjMc30wb0j8XV51HsMc/rZUhk0SPNY3r/6vvZ1QQHxl+rXvc3ejKO9zph5FZBrUzuvRQPmY1K8H7vSLa4lpbbZS/HUi9nk/2rwadD8cWbtKPYOL3EUn+cx5ZHeV1u51TO4DZpFamXm5qGOus96oECZYgqfThRsqyQQOlrARWBZ5K4TSOgZpgPlX4YOy4kU5c7KG8jCL7ymATRY3426YK/pNQpABYbEn02/cAS5iCKN+uZkvQn1s dZ8/2hLZ WnP5utpSZzFzUunuJhkwYgzWImkH3LMzERph36HnsVsA2iqsBRGmtFdskN4gIPww4I+haMffBIChhOcUTZeskVRRKJ2XH8d3mPLmolxUV2YTKQAbcb8eC7rGYcdb3rR1KRFI70foDFKfeM6XIX7HrXkJ1SgxyZAuf6gZBQ9UZxZhP8I6CU/Fp8jiqA1g2aeBkVbgFd9PT2s61LfndK3o0/eELmXwUR7nJhU0Xkw03ja3PpYHNit7XG68VfiJ5z28p5zXxOSQdpqjh3Yp4TAAwsojAsVrDA7eLv9z4amIV5D9KbbZCBYa5CTGAuSTb6lw4zbA4 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. > > 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 personally find it confusing to add all IOMMU page-table allocations to SecPageTables, considering that userspace could be using that today with a reasonable expectation that it's concerned only with virtual machine overhead. However, if the opposite conclusion was reached at LPC, then I really don't want to re-open the discussion and derail your patchset. Will