| Message ID | 20240308092721.144735-1-21cnbao@gmail.com (mailing list archive) |
|---|---|
| State | New |
| Headers | show |
| Series | [v2] mm: prohibit the last subpage from reusing the entire large folio | expand |
>>> This patch migrates the last subpage to a small folio and immediately >>> returns the large folio to the system. It benefits both memory availability >>> and anti-fragmentation. >> >> It might be controversial optimization, and as Ryan said, there, are likely >> other cases where we'd want to migrate off-of a thp if possible earlier. > > Personally, I think there might also be cases where you want to copy/reuse the > entire large folio. If you're application is using 16K THPs perhaps it's a > bigger win to just treat it like a base page? I expect the cost/benefit will > change as the THP size increases? Yes, I think for small folios (i.e., 16KiB) it will be rather easy to make a decision. The larger the folio, the larger the page fault latency due to scanning, copying, modifying, which can easily turn undesirable. At least when it comes to page reuse, I have some simple backup plans for small folios if I won't be able to make progress with my other approach. For larger folios, it won't really work/be desirable, though.
On 08/03/2024 13:24, David Hildenbrand wrote: >>>> This patch migrates the last subpage to a small folio and immediately >>>> returns the large folio to the system. It benefits both memory availability >>>> and anti-fragmentation. >>> >>> It might be controversial optimization, and as Ryan said, there, are likely >>> other cases where we'd want to migrate off-of a thp if possible earlier. >> >> Personally, I think there might also be cases where you want to copy/reuse the >> entire large folio. If you're application is using 16K THPs perhaps it's a >> bigger win to just treat it like a base page? I expect the cost/benefit will >> change as the THP size increases? > > Yes, I think for small folios (i.e., 16KiB) it will be rather easy to make a > decision. The larger the folio, the larger the page fault latency due to > scanning, copying, modifying, which can easily turn undesirable. > > At least when it comes to page reuse, I have some simple backup plans for small > folios if I won't be able to make progress with my other approach. Do you mean "small large folios" here? i.e. order >= 1? If so, great! For larger > folios, it won't really work/be desirable, though. >
On 08.03.24 14:45, Ryan Roberts wrote: > On 08/03/2024 13:24, David Hildenbrand wrote: >>>>> This patch migrates the last subpage to a small folio and immediately >>>>> returns the large folio to the system. It benefits both memory availability >>>>> and anti-fragmentation. >>>> >>>> It might be controversial optimization, and as Ryan said, there, are likely >>>> other cases where we'd want to migrate off-of a thp if possible earlier. >>> >>> Personally, I think there might also be cases where you want to copy/reuse the >>> entire large folio. If you're application is using 16K THPs perhaps it's a >>> bigger win to just treat it like a base page? I expect the cost/benefit will >>> change as the THP size increases? >> >> Yes, I think for small folios (i.e., 16KiB) it will be rather easy to make a >> decision. The larger the folio, the larger the page fault latency due to >> scanning, copying, modifying, which can easily turn undesirable. >> >> At least when it comes to page reuse, I have some simple backup plans for small >> folios if I won't be able to make progress with my other approach. > > Do you mean "small large folios" here? i.e. order >= 1? If so, great! *smaller*, yes :)
diff --git a/mm/memory.c b/mm/memory.c index e17669d4f72f..f2bc6dd15eb8 100644 --- a/mm/memory.c +++ b/mm/memory.c @@ -3498,6 +3498,16 @@ static vm_fault_t wp_page_shared(struct vm_fault *vmf, struct folio *folio) static bool wp_can_reuse_anon_folio(struct folio *folio, struct vm_area_struct *vma) { + /* + * We could currently only reuse a subpage of a large folio if no + * other subpages of the large folios are still mapped. However, + * let's just consistently not reuse subpages even if we could + * reuse in that scenario, and give back a large folio a bit + * sooner. + */ + if (folio_test_large(folio)) + return false; + /* * We have to verify under folio lock: these early checks are * just an optimization to avoid locking the folio and freeing