For example, create three task: hot1 -> cold -> hot2. After all three
task are created, each allocate memory 128MB. the hot1/hot2 task
continuously access 128 MB memory, while the cold task only accesses
its memory briefly andthen call madvise(MADV_COLD). However, khugepaged
still prioritizes scanning the cold task and only scans the hot2 task
after completing the scan of the cold task.
So if the user has explicitly informed us via MADV_COLD/FREE that this
memory is cold or will be freed, it is appropriate for khugepaged to
skip it only, thereby avoiding unnecessary scan and collapse operations
to reducing CPU wastage.
Here are the performance test results:
(Throughput bigger is better, other smaller is better)
Testing on x86_64 machine:
| task hot2 | without patch | with patch | delta |
|---------------------|---------------|---------------|---------|
| total accesses time | 3.14 sec | 2.93 sec | -6.69% |
| cycles per access | 4.96 | 2.21 | -55.44% |
| Throughput | 104.38 M/sec | 111.89 M/sec | +7.19% |
| dTLB-load-misses | 284814532 | 69597236 | -75.56% |
Testing on qemu-system-x86_64 -enable-kvm:
| task hot2 | without patch | with patch | delta |
|---------------------|---------------|---------------|---------|
| total accesses time | 3.35 sec | 2.96 sec | -11.64% |
| cycles per access | 7.29 | 2.07 | -71.60% |
| Throughput | 97.67 M/sec | 110.77 M/sec | +13.41% |
| dTLB-load-misses | 241600871 | 3216108 | -98.67% |
Signed-off-by: Vernon Yang <yanglincheng@kylinos.cn>
---
mm/madvise.c | 17 ++++++++++++-----
1 file changed, 12 insertions(+), 5 deletions(-)
diff --git a/mm/madvise.c b/mm/madvise.c
index b617b1be0f53..3a48d725a3fc 100644
--- a/mm/madvise.c
+++ b/mm/madvise.c
@@ -1360,11 +1360,8 @@ static int madvise_vma_behavior(struct madvise_behavior *madv_behavior)
return madvise_remove(madv_behavior);
case MADV_WILLNEED:
return madvise_willneed(madv_behavior);
- case MADV_COLD:
- return madvise_cold(madv_behavior);
case MADV_PAGEOUT:
return madvise_pageout(madv_behavior);
- case MADV_FREE:
case MADV_DONTNEED:
case MADV_DONTNEED_LOCKED:
return madvise_dontneed_free(madv_behavior);
@@ -1378,6 +1375,18 @@ static int madvise_vma_behavior(struct madvise_behavior *madv_behavior)
/* The below behaviours update VMAs via madvise_update_vma(). */
+ case MADV_COLD:
+ error = madvise_cold(madv_behavior);
+ if (error)
+ goto out;
+ new_flags = (new_flags & ~VM_HUGEPAGE) | VM_NOHUGEPAGE;
+ break;
+ case MADV_FREE:
+ error = madvise_dontneed_free(madv_behavior);
+ if (error)
+ goto out;
+ new_flags = (new_flags & ~VM_HUGEPAGE) | VM_NOHUGEPAGE;
+ break;
case MADV_NORMAL:
new_flags = new_flags & ~VM_RAND_READ & ~VM_SEQ_READ;
break;
@@ -1756,7 +1765,6 @@ static enum madvise_lock_mode get_lock_mode(struct madvise_behavior *madv_behavi
switch (madv_behavior->behavior) {
case MADV_REMOVE:
case MADV_WILLNEED:
- case MADV_COLD:
case MADV_PAGEOUT:
case MADV_POPULATE_READ:
case MADV_POPULATE_WRITE:
@@ -1766,7 +1774,6 @@ static enum madvise_lock_mode get_lock_mode(struct madvise_behavior *madv_behavi
case MADV_GUARD_REMOVE:
case MADV_DONTNEED:
case MADV_DONTNEED_LOCKED:
- case MADV_FREE:
return MADVISE_VMA_READ_LOCK;
default:
return MADVISE_MMAP_WRITE_LOCK;
--
2.51.0On 12/29/25 06:51, Vernon Yang wrote:
> For example, create three task: hot1 -> cold -> hot2. After all three
> task are created, each allocate memory 128MB. the hot1/hot2 task
> continuously access 128 MB memory, while the cold task only accesses
> its memory briefly andthen call madvise(MADV_COLD). However, khugepaged
> still prioritizes scanning the cold task and only scans the hot2 task
> after completing the scan of the cold task.
>
> So if the user has explicitly informed us via MADV_COLD/FREE that this
> memory is cold or will be freed, it is appropriate for khugepaged to
> skip it only, thereby avoiding unnecessary scan and collapse operations
> to reducing CPU wastage.
>
> Here are the performance test results:
> (Throughput bigger is better, other smaller is better)
>
> Testing on x86_64 machine:
>
> | task hot2 | without patch | with patch | delta |
> |---------------------|---------------|---------------|---------|
> | total accesses time | 3.14 sec | 2.93 sec | -6.69% |
> | cycles per access | 4.96 | 2.21 | -55.44% |
> | Throughput | 104.38 M/sec | 111.89 M/sec | +7.19% |
> | dTLB-load-misses | 284814532 | 69597236 | -75.56% |
>
> Testing on qemu-system-x86_64 -enable-kvm:
>
> | task hot2 | without patch | with patch | delta |
> |---------------------|---------------|---------------|---------|
> | total accesses time | 3.35 sec | 2.96 sec | -11.64% |
> | cycles per access | 7.29 | 2.07 | -71.60% |
> | Throughput | 97.67 M/sec | 110.77 M/sec | +13.41% |
> | dTLB-load-misses | 241600871 | 3216108 | -98.67% |
>
> Signed-off-by: Vernon Yang <yanglincheng@kylinos.cn>
> ---
As raised in v1, this is not the way to go. Just because something was
once indicated to be cold does not meant that it will stay like that
forever.
Also,
(1) You are turning this into an operation that will perform VMA
modifications and require the mmap lock in write mode, bad.
(2) You might now create many VMAs, possibly breaking user space, bad.
If user space knows that memory will stay cold, it can use madvise() to
indicate that these regions are not a good fit for THPs.
But are they really not a good fit? What about smaller-order THPs?
Nobody knows, but changing the behavior like you suggest is definetly
bad. :)
--
Cheers
David
On Tue, Dec 30, 2025 at 08:54:33PM +0100, David Hildenbrand (Red Hat) wrote: > On 12/29/25 06:51, Vernon Yang wrote: > > For example, create three task: hot1 -> cold -> hot2. After all three > > task are created, each allocate memory 128MB. the hot1/hot2 task > > continuously access 128 MB memory, while the cold task only accesses > > its memory briefly andthen call madvise(MADV_COLD). However, khugepaged > > still prioritizes scanning the cold task and only scans the hot2 task > > after completing the scan of the cold task. > > > > So if the user has explicitly informed us via MADV_COLD/FREE that this > > memory is cold or will be freed, it is appropriate for khugepaged to > > skip it only, thereby avoiding unnecessary scan and collapse operations > > to reducing CPU wastage. > > > > Here are the performance test results: > > (Throughput bigger is better, other smaller is better) > > > > Testing on x86_64 machine: > > > > | task hot2 | without patch | with patch | delta | > > |---------------------|---------------|---------------|---------| > > | total accesses time | 3.14 sec | 2.93 sec | -6.69% | > > | cycles per access | 4.96 | 2.21 | -55.44% | > > | Throughput | 104.38 M/sec | 111.89 M/sec | +7.19% | > > | dTLB-load-misses | 284814532 | 69597236 | -75.56% | > > > > Testing on qemu-system-x86_64 -enable-kvm: > > > > | task hot2 | without patch | with patch | delta | > > |---------------------|---------------|---------------|---------| > > | total accesses time | 3.35 sec | 2.96 sec | -11.64% | > > | cycles per access | 7.29 | 2.07 | -71.60% | > > | Throughput | 97.67 M/sec | 110.77 M/sec | +13.41% | > > | dTLB-load-misses | 241600871 | 3216108 | -98.67% | > > > > Signed-off-by: Vernon Yang <yanglincheng@kylinos.cn> > > --- > > As raised in v1, this is not the way to go. Just because something was once > indicated to be cold does not meant that it will stay like that forever. > > Also, > > (1) You are turning this into an operation that will perform VMA > modifications and require the mmap lock in write mode, bad. > > (2) You might now create many VMAs, possibly breaking user space, bad. > > If user space knows that memory will stay cold, it can use madvise() to > indicate that these regions are not a good fit for THPs. > > But are they really not a good fit? What about smaller-order THPs? > > Nobody knows, but changing the behavior like you suggest is definetly bad. > :) > Thank you for review and explanation. I got it. For MADV_FREE, we will skip the lazy-free folios instead. For MADV_COLD, it will be removed in the next version. -- Thanks, Vernon
On 12/31/25 13:13, Vernon Yang wrote: > On Tue, Dec 30, 2025 at 08:54:33PM +0100, David Hildenbrand (Red Hat) wrote: >> On 12/29/25 06:51, Vernon Yang wrote: >>> For example, create three task: hot1 -> cold -> hot2. After all three >>> task are created, each allocate memory 128MB. the hot1/hot2 task >>> continuously access 128 MB memory, while the cold task only accesses >>> its memory briefly andthen call madvise(MADV_COLD). However, khugepaged >>> still prioritizes scanning the cold task and only scans the hot2 task >>> after completing the scan of the cold task. >>> >>> So if the user has explicitly informed us via MADV_COLD/FREE that this >>> memory is cold or will be freed, it is appropriate for khugepaged to >>> skip it only, thereby avoiding unnecessary scan and collapse operations >>> to reducing CPU wastage. >>> >>> Here are the performance test results: >>> (Throughput bigger is better, other smaller is better) >>> >>> Testing on x86_64 machine: >>> >>> | task hot2 | without patch | with patch | delta | >>> |---------------------|---------------|---------------|---------| >>> | total accesses time | 3.14 sec | 2.93 sec | -6.69% | >>> | cycles per access | 4.96 | 2.21 | -55.44% | >>> | Throughput | 104.38 M/sec | 111.89 M/sec | +7.19% | >>> | dTLB-load-misses | 284814532 | 69597236 | -75.56% | >>> >>> Testing on qemu-system-x86_64 -enable-kvm: >>> >>> | task hot2 | without patch | with patch | delta | >>> |---------------------|---------------|---------------|---------| >>> | total accesses time | 3.35 sec | 2.96 sec | -11.64% | >>> | cycles per access | 7.29 | 2.07 | -71.60% | >>> | Throughput | 97.67 M/sec | 110.77 M/sec | +13.41% | >>> | dTLB-load-misses | 241600871 | 3216108 | -98.67% | >>> >>> Signed-off-by: Vernon Yang <yanglincheng@kylinos.cn> >>> --- >> >> As raised in v1, this is not the way to go. Just because something was once >> indicated to be cold does not meant that it will stay like that forever. >> >> Also, >> >> (1) You are turning this into an operation that will perform VMA >> modifications and require the mmap lock in write mode, bad. >> >> (2) You might now create many VMAs, possibly breaking user space, bad. >> >> If user space knows that memory will stay cold, it can use madvise() to >> indicate that these regions are not a good fit for THPs. >> >> But are they really not a good fit? What about smaller-order THPs? >> >> Nobody knows, but changing the behavior like you suggest is definetly bad. >> :) >> > > Thank you for review and explanation. I got it. > > For MADV_FREE, we will skip the lazy-free folios instead. > For MADV_COLD, it will be removed in the next version. Just to be clear, setting VM_NOHUGEPAGE should not be done from any of these operations. Treating lazyfree folios differently in khugepaged code could indeed make sense. -- Cheers David
On Mon, Dec 29, 2025 at 6:52 PM Vernon Yang <vernon2gm@gmail.com> wrote: > > For example, create three task: hot1 -> cold -> hot2. After all three > task are created, each allocate memory 128MB. the hot1/hot2 task > continuously access 128 MB memory, while the cold task only accesses > its memory briefly andthen call madvise(MADV_COLD). However, khugepaged > still prioritizes scanning the cold task and only scans the hot2 task > after completing the scan of the cold task. > > So if the user has explicitly informed us via MADV_COLD/FREE that this > memory is cold or will be freed, it is appropriate for khugepaged to > skip it only, thereby avoiding unnecessary scan and collapse operations > to reducing CPU wastage. > > Here are the performance test results: > (Throughput bigger is better, other smaller is better) > > Testing on x86_64 machine: > > | task hot2 | without patch | with patch | delta | > |---------------------|---------------|---------------|---------| > | total accesses time | 3.14 sec | 2.93 sec | -6.69% | > | cycles per access | 4.96 | 2.21 | -55.44% | > | Throughput | 104.38 M/sec | 111.89 M/sec | +7.19% | > | dTLB-load-misses | 284814532 | 69597236 | -75.56% | > > Testing on qemu-system-x86_64 -enable-kvm: > > | task hot2 | without patch | with patch | delta | > |---------------------|---------------|---------------|---------| > | total accesses time | 3.35 sec | 2.96 sec | -11.64% | > | cycles per access | 7.29 | 2.07 | -71.60% | > | Throughput | 97.67 M/sec | 110.77 M/sec | +13.41% | > | dTLB-load-misses | 241600871 | 3216108 | -98.67% | > > Signed-off-by: Vernon Yang <yanglincheng@kylinos.cn> > --- > mm/madvise.c | 17 ++++++++++++----- > 1 file changed, 12 insertions(+), 5 deletions(-) > > diff --git a/mm/madvise.c b/mm/madvise.c > index b617b1be0f53..3a48d725a3fc 100644 > --- a/mm/madvise.c > +++ b/mm/madvise.c > @@ -1360,11 +1360,8 @@ static int madvise_vma_behavior(struct madvise_behavior *madv_behavior) > return madvise_remove(madv_behavior); > case MADV_WILLNEED: > return madvise_willneed(madv_behavior); > - case MADV_COLD: > - return madvise_cold(madv_behavior); > case MADV_PAGEOUT: > return madvise_pageout(madv_behavior); > - case MADV_FREE: > case MADV_DONTNEED: > case MADV_DONTNEED_LOCKED: > return madvise_dontneed_free(madv_behavior); > @@ -1378,6 +1375,18 @@ static int madvise_vma_behavior(struct madvise_behavior *madv_behavior) > > /* The below behaviours update VMAs via madvise_update_vma(). */ > > + case MADV_COLD: > + error = madvise_cold(madv_behavior); > + if (error) > + goto out; > + new_flags = (new_flags & ~VM_HUGEPAGE) | VM_NOHUGEPAGE; > + break; > + case MADV_FREE: > + error = madvise_dontneed_free(madv_behavior); > + if (error) > + goto out; > + new_flags = (new_flags & ~VM_HUGEPAGE) | VM_NOHUGEPAGE; > + break; I am not convinced this is the right patch for MADV_FREE. Userspace heaps may call MADV_FREE on free(), which does not mean they no longer want huge pages; it only indicates that the old contents are no longer needed. New allocations may still occur in the same region. The same concern applies to MADV_COLD. MADV_COLD may only indicate that the VMA is cold at the moment and for the near future, but it can become hot again. For example, MADV_COLD may be issued when an app moves to the background, but the memory can become hot again once the app returns to the foreground. In short, MADV_FREE and MADV_COLD only indicate that the memory is cold or may be freed for a period of time; they are not permanent states. Changing the VMA flags implies that the VMA is permanently free or cold, which is not true in either case. Your patch also prevents potential per-VMA lock optimizations. However, if the intent is to treat folios hinted by MADV_FREE or MADV_COLD as candidates not to be collapsed, I agree that this makes sense. For MADV_FREE, could we simply skip the lazy-free folios instead? For MADV_COLD, I am not sure how we can determine which folios have actually been madvised as cold. Thanks Barry
On Mon, Dec 29, 2025 at 09:20:12PM +1300, Barry Song wrote: > On Mon, Dec 29, 2025 at 6:52 PM Vernon Yang <vernon2gm@gmail.com> wrote: > > > > For example, create three task: hot1 -> cold -> hot2. After all three > > task are created, each allocate memory 128MB. the hot1/hot2 task > > continuously access 128 MB memory, while the cold task only accesses > > its memory briefly andthen call madvise(MADV_COLD). However, khugepaged > > still prioritizes scanning the cold task and only scans the hot2 task > > after completing the scan of the cold task. > > > > So if the user has explicitly informed us via MADV_COLD/FREE that this > > memory is cold or will be freed, it is appropriate for khugepaged to > > skip it only, thereby avoiding unnecessary scan and collapse operations > > to reducing CPU wastage. > > > > Here are the performance test results: > > (Throughput bigger is better, other smaller is better) > > > > Testing on x86_64 machine: > > > > | task hot2 | without patch | with patch | delta | > > |---------------------|---------------|---------------|---------| > > | total accesses time | 3.14 sec | 2.93 sec | -6.69% | > > | cycles per access | 4.96 | 2.21 | -55.44% | > > | Throughput | 104.38 M/sec | 111.89 M/sec | +7.19% | > > | dTLB-load-misses | 284814532 | 69597236 | -75.56% | > > > > Testing on qemu-system-x86_64 -enable-kvm: > > > > | task hot2 | without patch | with patch | delta | > > |---------------------|---------------|---------------|---------| > > | total accesses time | 3.35 sec | 2.96 sec | -11.64% | > > | cycles per access | 7.29 | 2.07 | -71.60% | > > | Throughput | 97.67 M/sec | 110.77 M/sec | +13.41% | > > | dTLB-load-misses | 241600871 | 3216108 | -98.67% | > > > > Signed-off-by: Vernon Yang <yanglincheng@kylinos.cn> > > --- > > mm/madvise.c | 17 ++++++++++++----- > > 1 file changed, 12 insertions(+), 5 deletions(-) > > > > diff --git a/mm/madvise.c b/mm/madvise.c > > index b617b1be0f53..3a48d725a3fc 100644 > > --- a/mm/madvise.c > > +++ b/mm/madvise.c > > @@ -1360,11 +1360,8 @@ static int madvise_vma_behavior(struct madvise_behavior *madv_behavior) > > return madvise_remove(madv_behavior); > > case MADV_WILLNEED: > > return madvise_willneed(madv_behavior); > > - case MADV_COLD: > > - return madvise_cold(madv_behavior); > > case MADV_PAGEOUT: > > return madvise_pageout(madv_behavior); > > - case MADV_FREE: > > case MADV_DONTNEED: > > case MADV_DONTNEED_LOCKED: > > return madvise_dontneed_free(madv_behavior); > > @@ -1378,6 +1375,18 @@ static int madvise_vma_behavior(struct madvise_behavior *madv_behavior) > > > > /* The below behaviours update VMAs via madvise_update_vma(). */ > > > > + case MADV_COLD: > > + error = madvise_cold(madv_behavior); > > + if (error) > > + goto out; > > + new_flags = (new_flags & ~VM_HUGEPAGE) | VM_NOHUGEPAGE; > > + break; > > + case MADV_FREE: > > + error = madvise_dontneed_free(madv_behavior); > > + if (error) > > + goto out; > > + new_flags = (new_flags & ~VM_HUGEPAGE) | VM_NOHUGEPAGE; > > + break; > > I am not convinced this is the right patch for MADV_FREE. Userspace > heaps may call MADV_FREE on free(), which does not mean they no longer > want huge pages; it only indicates that the old contents are no longer > needed. New allocations may still occur in the same region. > > The same concern applies to MADV_COLD. MADV_COLD may only indicate > that the VMA is cold at the moment and for the near future, but it > can become hot again. For example, MADV_COLD may be issued when an > app moves to the background, but the memory can become hot again > once the app returns to the foreground. > > In short, MADV_FREE and MADV_COLD only indicate that the memory is cold > or may be freed for a period of time; they are not permanent states. > Changing the VMA flags implies that the VMA is permanently free or > cold, which is not true in either case. > > Your patch also prevents potential per-VMA lock optimizations. Thank you for review and explanation. > However, if the intent is to treat folios hinted by MADV_FREE or > MADV_COLD as candidates not to be collapsed, I agree that this makes sense. > > For MADV_FREE, could we simply skip the lazy-free folios instead? It is nice that skiping lazy-free folios simply, it has the same performance. Thanks for your suggestions, I will send it at the next version. > For MADV_COLD, I am not sure how we can determine which folios > have actually been madvised as cold. It is a tricky problem, I don't have a good solution for at the moment :( Does anyone have any good ideas? please let me know, thanks! If not, it might be removed in the next version. -- Thanks, Vernon
On 29/12/25 1:50 pm, Barry Song wrote: > On Mon, Dec 29, 2025 at 6:52 PM Vernon Yang <vernon2gm@gmail.com> wrote: >> For example, create three task: hot1 -> cold -> hot2. After all three >> task are created, each allocate memory 128MB. the hot1/hot2 task >> continuously access 128 MB memory, while the cold task only accesses >> its memory briefly andthen call madvise(MADV_COLD). However, khugepaged >> still prioritizes scanning the cold task and only scans the hot2 task >> after completing the scan of the cold task. >> >> So if the user has explicitly informed us via MADV_COLD/FREE that this >> memory is cold or will be freed, it is appropriate for khugepaged to >> skip it only, thereby avoiding unnecessary scan and collapse operations >> to reducing CPU wastage. >> >> Here are the performance test results: >> (Throughput bigger is better, other smaller is better) >> >> Testing on x86_64 machine: >> >> | task hot2 | without patch | with patch | delta | >> |---------------------|---------------|---------------|---------| >> | total accesses time | 3.14 sec | 2.93 sec | -6.69% | >> | cycles per access | 4.96 | 2.21 | -55.44% | >> | Throughput | 104.38 M/sec | 111.89 M/sec | +7.19% | >> | dTLB-load-misses | 284814532 | 69597236 | -75.56% | >> >> Testing on qemu-system-x86_64 -enable-kvm: >> >> | task hot2 | without patch | with patch | delta | >> |---------------------|---------------|---------------|---------| >> | total accesses time | 3.35 sec | 2.96 sec | -11.64% | >> | cycles per access | 7.29 | 2.07 | -71.60% | >> | Throughput | 97.67 M/sec | 110.77 M/sec | +13.41% | >> | dTLB-load-misses | 241600871 | 3216108 | -98.67% | >> >> Signed-off-by: Vernon Yang <yanglincheng@kylinos.cn> >> --- >> mm/madvise.c | 17 ++++++++++++----- >> 1 file changed, 12 insertions(+), 5 deletions(-) >> >> diff --git a/mm/madvise.c b/mm/madvise.c >> index b617b1be0f53..3a48d725a3fc 100644 >> --- a/mm/madvise.c >> +++ b/mm/madvise.c >> @@ -1360,11 +1360,8 @@ static int madvise_vma_behavior(struct madvise_behavior *madv_behavior) >> return madvise_remove(madv_behavior); >> case MADV_WILLNEED: >> return madvise_willneed(madv_behavior); >> - case MADV_COLD: >> - return madvise_cold(madv_behavior); >> case MADV_PAGEOUT: >> return madvise_pageout(madv_behavior); >> - case MADV_FREE: >> case MADV_DONTNEED: >> case MADV_DONTNEED_LOCKED: >> return madvise_dontneed_free(madv_behavior); >> @@ -1378,6 +1375,18 @@ static int madvise_vma_behavior(struct madvise_behavior *madv_behavior) >> >> /* The below behaviours update VMAs via madvise_update_vma(). */ >> >> + case MADV_COLD: >> + error = madvise_cold(madv_behavior); >> + if (error) >> + goto out; >> + new_flags = (new_flags & ~VM_HUGEPAGE) | VM_NOHUGEPAGE; >> + break; >> + case MADV_FREE: >> + error = madvise_dontneed_free(madv_behavior); >> + if (error) >> + goto out; >> + new_flags = (new_flags & ~VM_HUGEPAGE) | VM_NOHUGEPAGE; >> + break; > I am not convinced this is the right patch for MADV_FREE. Userspace > heaps may call MADV_FREE on free(), which does not mean they no longer > want huge pages; it only indicates that the old contents are no longer > needed. New allocations may still occur in the same region. +1. Userspace allocators do MADV_DONTNEED/MADV_FREE to prevent overhead of actually unmapping the memory via munmap. > > The same concern applies to MADV_COLD. MADV_COLD may only indicate > that the VMA is cold at the moment and for the near future, but it > can become hot again. For example, MADV_COLD may be issued when an > app moves to the background, but the memory can become hot again > once the app returns to the foreground. > > In short, MADV_FREE and MADV_COLD only indicate that the memory is cold > or may be freed for a period of time; they are not permanent states. > Changing the VMA flags implies that the VMA is permanently free or > cold, which is not true in either case. > > Your patch also prevents potential per-VMA lock optimizations. > > However, if the intent is to treat folios hinted by MADV_FREE or > MADV_COLD as candidates not to be collapsed, I agree that this makes sense. > > For MADV_FREE, could we simply skip the lazy-free folios instead? > For MADV_COLD, I am not sure how we can determine which folios > have actually been madvised as cold. > > Thanks > Barry
© 2016 - 2026 Red Hat, Inc.