[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <Y9kfn4YX59PIxj7+@nvidia.com>
Date: Tue, 31 Jan 2023 10:03:11 -0400
From: Jason Gunthorpe <jgg@...dia.com>
To: David Hildenbrand <david@...hat.com>
Cc: Alistair Popple <apopple@...dia.com>, linux-mm@...ck.org,
cgroups@...r.kernel.org, linux-kernel@...r.kernel.org,
jhubbard@...dia.com, tjmercier@...gle.com, hannes@...xchg.org,
surenb@...gle.com, mkoutny@...e.com, daniel@...ll.ch
Subject: Re: [RFC PATCH 00/19] mm: Introduce a cgroup to limit the amount of
locked and pinned memory
On Tue, Jan 31, 2023 at 02:57:20PM +0100, David Hildenbrand wrote:
> > I'm excited by this series, thanks for making it.
> >
> > The pin accounting has been a long standing problem and cgroups will
> > really help!
>
> Indeed. I'm curious how GUP-fast, pinning the same page multiple times, and
> pinning subpages of larger folios are handled :)
The same as today. The pinning is done based on the result from GUP,
and we charge every returned struct page.
So duplicates are counted multiple times, folios are ignored.
Removing duplicate charges would be costly, it would require storage
to keep track of how many times individual pages have been charged to
each cgroup (eg an xarray indexed by PFN of integers in each cgroup).
It doesn't seem worth the cost, IMHO.
We've made alot of investment now with iommufd to remove the most
annoying sources of duplicated pins so it is much less of a problem in
the qemu context at least.
Jason
Powered by blists - more mailing lists