On Fri, Feb 16, 2024 at 12:58 PM Will Deacon <will@xxxxxxxxxx> 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? Pasha
