On Fri, Feb 16, 2024 at 02:48:00PM -0500, Pasha Tatashin wrote: > 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? 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
