On Fri, 15 Dec 2023, Pasha Tatashin wrote: > > > diff --git a/Documentation/admin-guide/cgroup-v2.rst b/Documentation/admin-guide/cgroup-v2.rst > > > index 3f85254f3cef..e004e05a7cde 100644 > > > --- a/Documentation/admin-guide/cgroup-v2.rst > > > +++ b/Documentation/admin-guide/cgroup-v2.rst > > > @@ -1418,7 +1418,7 @@ PAGE_SIZE multiple when read back. > > > sec_pagetables > > > Amount of memory allocated for secondary page tables, > > > this currently includes KVM mmu allocations on x86 > > > - and arm64. > > > + and arm64 and IOMMU page tables. > > > > Hmm, if existing users are parsing this field and alerting when it exceeds > > an expected value (a cloud provider, let's say), is it safe to add in a > > whole new set of page tables? > > > > I understand the documentation allows for it, but I think potential impact > > on userspace would be more interesting. > > Hi David, > > This is something that was discussed at LPC'23. I also was proposing a > separate counter for iommu page tables, but it was noted that we > specifically have sec_pagetables called this way to include all non > regular CPU page tables, and we should therefore account for them > together. > > Please also see this discussion from the previous version of this patch series: > https://lore.kernel.org/all/CAJD7tkb1FqTqwONrp2nphBDkEamQtPCOFm0208H3tp0Gq2OLMQ@xxxxxxxxxxxxxx/ > Gotcha, I think that makes sense. When sec_pagetables was introduced, I can understand the need to account for non-primary pagetables separately because of the long-standing behavior. In that sense, sec_pagetables becomes a dumping ground for "all other page tables" which IOMMU would naturally include. So this looks good to me. Acked-by: David Rientjes <rientjes@xxxxxxxxxx>
