| Message ID | 20241030030116.670307-1-jhubbard@nvidia.com (mailing list archive) |
|---|---|
| State | New |
| Headers | show |
| Series | mm/gup: restore the ability to pin more than 2GB at a time | expand |
On Tue, Oct 29, 2024 at 08:01:16PM -0700, John Hubbard wrote: > A user-visible consequence has now appeared: user space can no longer > pin more than 2GB of memory anymore on x86_64. That's because, on a 4KB > PAGE_SIZE system, when user space tries to (indirectly, via a device > driver that calls pin_user_pages()) pin 2GB, this requires an allocation > of a folio pointers array of MAX_PAGE_ORDER size, which is the limit for > kmalloc(). Do you have a report whee someone tries to pin that much memor in a single call? What driver is this? Because it seems like a not very smart thing to do.
On 10/29/24 9:21 PM, Christoph Hellwig wrote: > On Tue, Oct 29, 2024 at 08:01:16PM -0700, John Hubbard wrote: >> A user-visible consequence has now appeared: user space can no longer >> pin more than 2GB of memory anymore on x86_64. That's because, on a 4KB >> PAGE_SIZE system, when user space tries to (indirectly, via a device >> driver that calls pin_user_pages()) pin 2GB, this requires an allocation >> of a folio pointers array of MAX_PAGE_ORDER size, which is the limit for >> kmalloc(). > > Do you have a report whee someone tries to pin that much memor in a > single call? What driver is this? Because it seems like a not very > smart thing to do. > I do, yes. And what happens is that when you use GPUs, drivers like to pin system memory, and then point the GPU page tables to that memory. For older GPUs that don't support replayable page faults, that's required. So this behavior has been around forever. The customer was qualifying their software and noticed that before Linux 6.10, they could allocate >2GB, and with 6.11, they could not. Whether it is "wise" for user space to allocate that much at once is a reasonable question, but at least one place is (or was!) doing it. thanks,
On Tue, Oct 29, 2024 at 09:30:41PM -0700, John Hubbard wrote: > I do, yes. And what happens is that when you use GPUs, drivers like > to pin system memory, and then point the GPU page tables to that > memory. For older GPUs that don't support replayable page faults, > that's required. > > So this behavior has been around forever. > > The customer was qualifying their software and noticed that before > Linux 6.10, they could allocate >2GB, and with 6.11, they could > not. > > Whether it is "wise" for user space to allocate that much at once > is a reasonable question, but at least one place is (or was!) doing > it. Still missing a callchain, which make me suspect that it is your weird out of tree driver, in which case this simply does not matter.
On 10/29/24 9:33 PM, Christoph Hellwig wrote: > On Tue, Oct 29, 2024 at 09:30:41PM -0700, John Hubbard wrote: >> I do, yes. And what happens is that when you use GPUs, drivers like >> to pin system memory, and then point the GPU page tables to that >> memory. For older GPUs that don't support replayable page faults, >> that's required. >> >> So this behavior has been around forever. >> >> The customer was qualifying their software and noticed that before >> Linux 6.10, they could allocate >2GB, and with 6.11, they could >> not. >> >> Whether it is "wise" for user space to allocate that much at once >> is a reasonable question, but at least one place is (or was!) doing >> it. > > Still missing a callchain, which make me suspect that it is your weird > out of tree driver, in which case this simply does not matter. > I expect I could piece together something with Nouveau, given enough time and help from Ben Skeggs and Danillo and all... Yes, this originated with the out of tree driver. But it never occurred to me that upstream be uninterested in an obvious fix to an obvious regression. thanks,
On Tue, Oct 29, 2024 at 09:39:15PM -0700, John Hubbard wrote: > I expect I could piece together something with Nouveau, given enough > time and help from Ben Skeggs and Danillo and all... > > Yes, this originated with the out of tree driver. But it never occurred > to me that upstream be uninterested in an obvious fix to an obvious > regression. Because pinning down these amounts of memoryt is completely insane. I don't mind the switch to kvmalloc, but we need to put in an upper bound of what can be pinned.
On 10/29/24 9:42 PM, Christoph Hellwig wrote: > On Tue, Oct 29, 2024 at 09:39:15PM -0700, John Hubbard wrote: >> I expect I could piece together something with Nouveau, given enough >> time and help from Ben Skeggs and Danillo and all... >> >> Yes, this originated with the out of tree driver. But it never occurred >> to me that upstream be uninterested in an obvious fix to an obvious >> regression. > > Because pinning down these amounts of memoryt is completely insane. > I don't mind the switch to kvmalloc, but we need to put in an upper > bound of what can be pinned. I'm wondering though, how it is that we decide how much of the user's system we prevent them from using? :) People with hardware accelerators do not always have page fault capability, and yet these troublesome users insist on stacking their system full of DRAM and then pointing the accelerator to it. How would we choose a value? Memory sizes keep going up... thanks,
John Hubbard <jhubbard@nvidia.com> writes: > On 10/29/24 9:42 PM, Christoph Hellwig wrote: >> On Tue, Oct 29, 2024 at 09:39:15PM -0700, John Hubbard wrote: >>> I expect I could piece together something with Nouveau, given enough >>> time and help from Ben Skeggs and Danillo and all... >>> >>> Yes, this originated with the out of tree driver. But it never occurred >>> to me that upstream be uninterested in an obvious fix to an obvious >>> regression. >> Because pinning down these amounts of memoryt is completely insane. >> I don't mind the switch to kvmalloc, but we need to put in an upper >> bound of what can be pinned. > > I'm wondering though, how it is that we decide how much of the user's > system we prevent them from using? :) People with hardware accelerators > do not always have page fault capability, and yet these troublesome > users insist on stacking their system full of DRAM and then pointing > the accelerator to it. > > How would we choose a value? Memory sizes keep going up... The obvious answer is you let users decide. I did have a patch series to do that via a cgroup[1]. However I dropped that series mostly because I couldn't find any users of such a limit to provide feedback on how they would use it or how they wanted it to work. - Alistair [1] - https://lore.kernel.org/linux-mm/cover.c238416f0e82377b449846dbb2459ae9d7030c8e.1675669136.git-series.apopple@nvidia.com/ > thanks,
On 10/29/24 11:18 PM, Alistair Popple wrote: > John Hubbard <jhubbard@nvidia.com> writes: >> On 10/29/24 9:42 PM, Christoph Hellwig wrote: >>> On Tue, Oct 29, 2024 at 09:39:15PM -0700, John Hubbard wrote: ... >>> Because pinning down these amounts of memoryt is completely insane. >>> I don't mind the switch to kvmalloc, but we need to put in an upper >>> bound of what can be pinned. >> >> I'm wondering though, how it is that we decide how much of the user's >> system we prevent them from using? :) People with hardware accelerators >> do not always have page fault capability, and yet these troublesome >> users insist on stacking their system full of DRAM and then pointing >> the accelerator to it. >> >> How would we choose a value? Memory sizes keep going up... > > The obvious answer is you let users decide. I did have a patch series to > do that via a cgroup[1]. However I dropped that series mostly because I > couldn't find any users of such a limit to provide feedback on how they > would use it or how they wanted it to work. > Trawling through the discussion there, I see that Jason Gunthorpe mentioned: "Things like VFIO & KVM use cases effectively pin 90% of all system memory" ...which means that we'll be able to get that in-tree call trace that Christoph is asking for, pretty soon. No GPUs required. :) thanks,
On 30.10.24 07:50, John Hubbard wrote: > On 10/29/24 11:18 PM, Alistair Popple wrote: >> John Hubbard <jhubbard@nvidia.com> writes: >>> On 10/29/24 9:42 PM, Christoph Hellwig wrote: >>>> On Tue, Oct 29, 2024 at 09:39:15PM -0700, John Hubbard wrote: > ... >>>> Because pinning down these amounts of memoryt is completely insane. >>>> I don't mind the switch to kvmalloc, but we need to put in an upper >>>> bound of what can be pinned. >>> >>> I'm wondering though, how it is that we decide how much of the user's >>> system we prevent them from using? :) People with hardware accelerators >>> do not always have page fault capability, and yet these troublesome >>> users insist on stacking their system full of DRAM and then pointing >>> the accelerator to it. >>> >>> How would we choose a value? Memory sizes keep going up... >> >> The obvious answer is you let users decide. I did have a patch series to >> do that via a cgroup[1]. However I dropped that series mostly because I >> couldn't find any users of such a limit to provide feedback on how they >> would use it or how they wanted it to work. >> > > Trawling through the discussion there, I see that Jason Gunthorpe mentioned: > > "Things like VFIO & KVM use cases effectively pin 90% of all system memory" The unusual thing is not the amount of system memory we are pinning but *how many* pages we try pinning in the single call. If you stare at vfio_pin_pages_remote, we seem to be batching it. long req_pages = min_t(long, npage, batch->capacity); Which is #define VFIO_BATCH_MAX_CAPACITY (PAGE_SIZE / sizeof(struct page *)) So you can fix this in your driver ;) We should maybe try a similar limit internally: if you call pin_user_pages_remote() with a large number, we'll cap it at some magic value (similar to above). The caller will simply realize that not all pages were pinned and will retry. See get_user_pages_remote(): "Returns either number of pages pinned (which may be less than the number requested), or an error. Details about the return value:" Alternatively, I recall there was a way to avoid the temporary allocation ... let me hack up a prototype real quick.
On 30.10.24 09:34, David Hildenbrand wrote: > On 30.10.24 07:50, John Hubbard wrote: >> On 10/29/24 11:18 PM, Alistair Popple wrote: >>> John Hubbard <jhubbard@nvidia.com> writes: >>>> On 10/29/24 9:42 PM, Christoph Hellwig wrote: >>>>> On Tue, Oct 29, 2024 at 09:39:15PM -0700, John Hubbard wrote: >> ... >>>>> Because pinning down these amounts of memoryt is completely insane. >>>>> I don't mind the switch to kvmalloc, but we need to put in an upper >>>>> bound of what can be pinned. >>>> >>>> I'm wondering though, how it is that we decide how much of the user's >>>> system we prevent them from using? :) People with hardware accelerators >>>> do not always have page fault capability, and yet these troublesome >>>> users insist on stacking their system full of DRAM and then pointing >>>> the accelerator to it. >>>> >>>> How would we choose a value? Memory sizes keep going up... >>> >>> The obvious answer is you let users decide. I did have a patch series to >>> do that via a cgroup[1]. However I dropped that series mostly because I >>> couldn't find any users of such a limit to provide feedback on how they >>> would use it or how they wanted it to work. >>> >> >> Trawling through the discussion there, I see that Jason Gunthorpe mentioned: >> >> "Things like VFIO & KVM use cases effectively pin 90% of all system memory" > > The unusual thing is not the amount of system memory we are pinning but > *how many* pages we try pinning in the single call. > > If you stare at vfio_pin_pages_remote, we seem to be batching it. > > long req_pages = min_t(long, npage, batch->capacity); > > Which is > > #define VFIO_BATCH_MAX_CAPACITY (PAGE_SIZE / sizeof(struct page *)) > > > So you can fix this in your driver ;) > > > We should maybe try a similar limit internally: if you call > pin_user_pages_remote() with a large number, we'll cap it at some magic > value (similar to above). The caller will simply realize that not all > pages were pinned and will retry. > > See get_user_pages_remote(): "Returns either number of pages pinned > (which may be less than the number requested), or an error. Details > about the return value:" > > > Alternatively, I recall there was a way to avoid the temporary > allocation ... let me hack up a prototype real quick. Completely untested (also note the interesting TODO): From a23984b4f1a39ec984489fbe16708aedf4f9db95 Mon Sep 17 00:00:00 2001 From: David Hildenbrand <david@redhat.com> Date: Wed, 30 Oct 2024 10:00:50 +0100 Subject: [PATCH] tmp Signed-off-by: David Hildenbrand <david@redhat.com> --- mm/gup.c | 120 ++++++++++++++++++++++++++++++++++++------------------- 1 file changed, 78 insertions(+), 42 deletions(-) diff --git a/mm/gup.c b/mm/gup.c index a82890b46a36..8807b36c2363 100644 --- a/mm/gup.c +++ b/mm/gup.c @@ -2273,20 +2273,56 @@ struct page *get_dump_page(unsigned long addr) #endif /* CONFIG_ELF_CORE */ #ifdef CONFIG_MIGRATION + +/* + * An array of either pages or folios. While we could currently interpret a + * list of folios like a list of pages, it would only work as long as + * "struct folio" overlays "struct page" -- and it would not allow for + * avoiding page_folio() calls. + */ +struct pages_or_folios { + union { + struct page **pages; + struct folio **folios; + void **entries; + }; + bool has_folios; + long nr_entries; +}; + +static struct folio *pofs_get_folio(struct pages_or_folios *pofs, long i) +{ + if (pofs->has_folios) + return pofs->folios[i]; + return page_folio(pofs->pages[i]); +} + +static void pofs_clear_entry(struct pages_or_folios *pofs, long i) +{ + pofs->entries[i] = NULL; +} + +static void pofs_unpin(struct pages_or_folios *pofs) +{ + if (pofs->has_folios) + unpin_folios(pofs->folios, pofs->nr_entries); + else + unpin_user_pages(pofs->pages, pofs->nr_entries); +} + /* * Returns the number of collected folios. Return value is always >= 0. */ static unsigned long collect_longterm_unpinnable_folios( - struct list_head *movable_folio_list, - unsigned long nr_folios, - struct folio **folios) + struct list_head *movable_folio_list, + struct pages_or_folios *pofs) { unsigned long i, collected = 0; struct folio *prev_folio = NULL; bool drain_allow = true; - for (i = 0; i < nr_folios; i++) { - struct folio *folio = folios[i]; + for (i = 0; i < pofs->nr_entries; i++) { + struct folio *folio = pofs_get_folio(pofs, i); if (folio == prev_folio) continue; @@ -2310,6 +2346,11 @@ static unsigned long collect_longterm_unpinnable_folios( drain_allow = false; } + /* + * TODO: if isolation fails we might already have it in the + * list, if pages of different folios are interleaved + * (e.g., COW). We might want to check all entries in the list. + */ if (!folio_isolate_lru(folio)) continue; @@ -2328,15 +2369,14 @@ static unsigned long collect_longterm_unpinnable_folios( * failure (or partial success). */ static int migrate_longterm_unpinnable_folios( - struct list_head *movable_folio_list, - unsigned long nr_folios, - struct folio **folios) + struct list_head *movable_folio_list, + struct pages_or_folios *pofs) { int ret; unsigned long i; - for (i = 0; i < nr_folios; i++) { - struct folio *folio = folios[i]; + for (i = 0; i < pofs->nr_entries; i++) { + struct folio *folio = pofs_get_folio(pofs, i); if (folio_is_device_coherent(folio)) { /* @@ -2344,7 +2384,7 @@ static int migrate_longterm_unpinnable_folios( * convert the pin on the source folio to a normal * reference. */ - folios[i] = NULL; + pofs_clear_entry(pofs, i); folio_get(folio); gup_put_folio(folio, 1, FOLL_PIN); @@ -2363,8 +2403,8 @@ static int migrate_longterm_unpinnable_folios( * calling folio_isolate_lru() which takes a reference so the * folio won't be freed if it's migrating. */ - unpin_folio(folios[i]); - folios[i] = NULL; + unpin_folio(pofs_get_folio(pofs, i)); + pofs_clear_entry(pofs, i); } if (!list_empty(movable_folio_list)) { @@ -2387,12 +2427,24 @@ static int migrate_longterm_unpinnable_folios( return -EAGAIN; err: - unpin_folios(folios, nr_folios); + pofs_unpin(pofs); putback_movable_pages(movable_folio_list); return ret; } +static long check_and_migrate_movable_pages_or_folios(struct pages_or_folios *pofs) +{ + LIST_HEAD(movable_folio_list); + unsigned long collected; + + collected = collect_longterm_unpinnable_folios(&movable_folio_list, pofs); + if (!collected) + return 0; + + return migrate_longterm_unpinnable_folios(&movable_folio_list, pofs); +} + /* * Check whether all folios are *allowed* to be pinned indefinitely (longterm). * Rather confusingly, all folios in the range are required to be pinned via @@ -2412,41 +2464,25 @@ static int migrate_longterm_unpinnable_folios( static long check_and_migrate_movable_folios(unsigned long nr_folios, struct folio **folios) { - unsigned long collected; - LIST_HEAD(movable_folio_list); - - collected = collect_longterm_unpinnable_folios(&movable_folio_list, - nr_folios, folios); - if (!collected) - return 0; + struct pages_or_folios pofs = { + .folios = folios, + .has_folios = true, + .nr_entries = nr_folios, + }; - return migrate_longterm_unpinnable_folios(&movable_folio_list, - nr_folios, folios); + return check_and_migrate_movable_pages_or_folios(&pofs); } -/* - * This routine just converts all the pages in the @pages array to folios and - * calls check_and_migrate_movable_folios() to do the heavy lifting. - * - * Please see the check_and_migrate_movable_folios() documentation for details. - */ +/* See check_and_migrate_movable_folios(). */ static long check_and_migrate_movable_pages(unsigned long nr_pages, struct page **pages) { - struct folio **folios; - long i, ret; + struct pages_or_folios pofs = { + .pages = pages, + .nr_entries = nr_pages, + }; - folios = kmalloc_array(nr_pages, sizeof(*folios), GFP_KERNEL); - if (!folios) - return -ENOMEM; - - for (i = 0; i < nr_pages; i++) - folios[i] = page_folio(pages[i]); - - ret = check_and_migrate_movable_folios(nr_pages, folios); - - kfree(folios); - return ret; + return check_and_migrate_movable_pages_or_folios(&pofs); } #else static long check_and_migrate_movable_pages(unsigned long nr_pages,
On 10/30/24 05:39, John Hubbard wrote: > On 10/29/24 9:33 PM, Christoph Hellwig wrote: >> On Tue, Oct 29, 2024 at 09:30:41PM -0700, John Hubbard wrote: >>> I do, yes. And what happens is that when you use GPUs, drivers like >>> to pin system memory, and then point the GPU page tables to that >>> memory. For older GPUs that don't support replayable page faults, >>> that's required. >>> >>> So this behavior has been around forever. >>> >>> The customer was qualifying their software and noticed that before >>> Linux 6.10, they could allocate >2GB, and with 6.11, they could >>> not. >>> >>> Whether it is "wise" for user space to allocate that much at once >>> is a reasonable question, but at least one place is (or was!) doing >>> it. >> >> Still missing a callchain, which make me suspect that it is your weird >> out of tree driver, in which case this simply does not matter. >> > > I expect I could piece together something with Nouveau, given enough > time and help from Ben Skeggs and Danillo and all... > > Yes, this originated with the out of tree driver. But it never occurred > to me that upstream be uninterested in an obvious fix to an obvious > regression. It might be a regression even if you don't try to pin over 2GB. high-order (>costly order) allocations can fail and/or cause disruptive reclaim/compaction cycles even below MAX_PAGE_ORDER and it's better to use kvmalloc if physical contiguity is not needed, it will attempt the physical kmalloc() allocation with __GFP_NORETRY (little disruption) and fallback to vmalloc() quickly. Of course if there's a way to avoid the allocation completely, even beter. > > thanks,
On Tue, Oct 29, 2024 at 09:42:10PM -0700, Christoph Hellwig wrote: > On Tue, Oct 29, 2024 at 09:39:15PM -0700, John Hubbard wrote: > > I expect I could piece together something with Nouveau, given enough > > time and help from Ben Skeggs and Danillo and all... > > > > Yes, this originated with the out of tree driver. But it never occurred > > to me that upstream be uninterested in an obvious fix to an obvious > > regression. > > Because pinning down these amounts of memoryt is completely insane. > I don't mind the switch to kvmalloc, but we need to put in an upper > bound of what can be pinned. I have RDMA customers that pin basically the entire machine's memory, which is 100Gb's of RAM. It is a dedicated server doing some HPC or Database job and it has been carefully setup to do that. Many VFIO VM deployments will pin almost all the memory too - just a little left over for the hypervisor. Again the machine was carefully setup to have huge pages that cover almost all system ram and are dedicated to backing memory for VMs. Pinning almost all memory is a legitimate use case. Jason
On Wed, Oct 30, 2024 at 09:34:51AM +0100, David Hildenbrand wrote: > The unusual thing is not the amount of system memory we are pinning but *how > many* pages we try pinning in the single call. > > If you stare at vfio_pin_pages_remote, we seem to be batching it. > > long req_pages = min_t(long, npage, batch->capacity); > > Which is > > #define VFIO_BATCH_MAX_CAPACITY (PAGE_SIZE / sizeof(struct page *)) > > So you can fix this in your driver ;) Yeah, everything batches that I'm aware of. RDMA also uses a 4k batch size, and iommufd uses 64k. Jason
diff --git a/mm/gup.c b/mm/gup.c index 4637dab7b54f..346186788a49 100644 --- a/mm/gup.c +++ b/mm/gup.c @@ -21,6 +21,7 @@ #include <linux/pagevec.h> #include <linux/sched/mm.h> #include <linux/shmem_fs.h> +#include <linux/vmalloc.h> #include <asm/mmu_context.h> #include <asm/tlbflush.h> @@ -2439,7 +2440,7 @@ static long check_and_migrate_movable_pages(unsigned long nr_pages, struct folio **folios; long i, ret; - folios = kmalloc_array(nr_pages, sizeof(*folios), GFP_KERNEL); + folios = kvmalloc_array(nr_pages, sizeof(*folios), GFP_KERNEL); if (!folios) { unpin_user_pages(pages, nr_pages); return -ENOMEM; @@ -2450,7 +2451,7 @@ static long check_and_migrate_movable_pages(unsigned long nr_pages, ret = check_and_migrate_movable_folios(nr_pages, folios); - kfree(folios); + kvfree(folios); return ret; } #else
commit 53ba78de064b ("mm/gup: introduce check_and_migrate_movable_folios()") created a new constraint on the pin_user_pages*() API family: a potentially large allocation must now occur, internally. A user-visible consequence has now appeared: user space can no longer pin more than 2GB of memory anymore on x86_64. That's because, on a 4KB PAGE_SIZE system, when user space tries to (indirectly, via a device driver that calls pin_user_pages()) pin 2GB, this requires an allocation of a folio pointers array of MAX_PAGE_ORDER size, which is the limit for kmalloc(). Fix this (restore the original behavior), by using replacing kmalloc_array() with kvmalloc_array(), which falls back to vmalloc() for larger allocations. Fixes: 53ba78de064b ("mm/gup: introduce check_and_migrate_movable_folios()") Cc: linux-stable@vger.kernel.org Cc: Vivek Kasireddy <vivek.kasireddy@intel.com> Cc: David Hildenbrand <david@redhat.com> Cc: Dave Airlie <airlied@redhat.com> Cc: Gerd Hoffmann <kraxel@redhat.com> Cc: Matthew Wilcox <willy@infradead.org> Cc: Christoph Hellwig <hch@infradead.org> Cc: Jason Gunthorpe <jgg@nvidia.com> Cc: Peter Xu <peterx@redhat.com> Cc: Arnd Bergmann <arnd@arndb.de> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Dongwon Kim <dongwon.kim@intel.com> Cc: Hugh Dickins <hughd@google.com> Cc: Junxiao Chang <junxiao.chang@intel.com> Cc: Mike Kravetz <mike.kravetz@oracle.com> Cc: Oscar Salvador <osalvador@suse.de> Signed-off-by: John Hubbard <jhubbard@nvidia.com> --- This applies to mm-hotfixes-unstable (only), because it relies on my earlier patch to this exact same location: commit 255231c75dcd mm/gup: stop leaking pinned pages in low memory conditions. thanks, John Hubbard mm/gup.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) base-commit: b70a32bbebeae216a3e846e01965880b309ca173