Re: [PATCH v2 10/10] iommu: account IOMMU allocated memory

David Rientjes
2023-12-24T21:44:16Z

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@mail.gmail.com/
>

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@google.com>