> > > > > 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. Thanks Jason, I will keep it as-is. I will send a new version soon with your comments addressed. > 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. +1! Memory profiling is going to be a very useful addition to the kernel. Pasha
