Messages in this thread | | | Date | Wed, 22 Feb 2023 16:05:50 -0800 | From | Christoph Hellwig <> | Subject | Re: [PATCH 14/19] mm: Introduce a cgroup for pinned memory |
| |
On Thu, Feb 23, 2023 at 09:59:35AM +1100, Alistair Popple wrote: > The idea was every driver already needs to allocate a pages array to > pass to pin_user_pages(), and by necessity drivers have to keep a > reference to the contents of that in one form or another. So > conceptually the equivalent of: > > struct vm_account { > struct list_head possible_pinners; > struct mem_cgroup *memcg; > struct pages **pages; > [...] > }; > > Unpinnig involves finding a new owner by traversing the list of > page->memcg_data->possible_pinners and iterating over *pages[] to figure > out if that vm_account actually has this page pinned or not and could > own it. > > Agree this is costly though. And I don't think all drivers keep the > array around so "iterating over *pages[]" may need to be a callback.
Is pinning in this context referring to FOLL_LONGTERM pins or any FOLL_PIN? In the latter case block based direct I/O does not keep the pages array around, and also is absolutely not willing to pay for the overhead.
For FOLL_LONGTERM the schemes sounds vaguely reasonable to me.
| |