From: xu xin <[email protected]>
The core idea of this patch set is to enable users to perceive the number of any
pages merged by KSM, regardless of whether use_zero_page switch has been turned
on, so that users can know how much free memory increase is really due to their
madvise(MERGEABLE) actions. But the problem is, when enabling use_zero_pages,
all empty pages will be merged with kernel zero pages instead of with each
other as use_zero_pages is disabled, and then these zero-pages are no longer
monitored by KSM.
The motivations for me to do this contains three points:
1) MADV_UNMERGEABLE and other ways to trigger unsharing will *not*
unshare the shared zeropage as placed by KSM (which is against the
MADV_UNMERGEABLE documentation at least); see the link:
https://lore.kernel.org/lkml/[email protected]/
2) We cannot know how many pages are zero pages placed by KSM when
enabling use_zero_pages, which hides the critical information about
how much actual memory are really saved by KSM. Knowing how many
ksm-placed zero pages are helpful for user to use the policy of madvise
(MERGEABLE) better because they can see the actual profit brought by KSM.
3) The zero pages placed-by KSM are different from those initial empty page
(filled with zeros) which are never touched by applications. The former
is active-merged by KSM while the later have never consume actual memory.
use_zero_pages is useful, not only because of cache colouring as described
in doc, but also because use_zero_pages can accelerate merging empty pages
when there are plenty of empty pages (full of zeros) as the time of
page-by-page comparisons (unstable_tree_search_insert) is saved. So we hope to
implement the support for ksm zero page tracking without affecting the feature
of use_zero_pages.
Zero pages may be the most common merged pages in actual environment(not only VM but
also including other application like containers). Enabling use_zero_pages in the
environment with plenty of empty pages(full of zeros) will be very useful. Users and
app developer can also benefit from knowing the proportion of zero pages in all
merged pages to optimize applications.
With the patch series, we can both unshare zero-pages(KSM-placed) accurately
and count ksm zero pages with enabling use_zero_pages.
v5->v6:
1) In [PATCH 1/6], fix some coments as Divid's suggestions [1].
2) In [PATCH 6/6], modify the patch as Divid's suggestions [2].
[1]: https://lore.kernel.org/lkml/[email protected]/
[2]: https://lore.kernel.org/lkml/[email protected]/
v4->v5:
---
1) fix warning: mm/ksm.c:3238:9: warning: no previous prototype for 'zero_pages_sharing_show'
[-Wmissing-prototypes].
In [PATCH 3/6] (ksm: count all zero pages placed by KSM), declare the function
ssize_t zero_pages_sharing_show(struct kobject *kobj...) as 'static'.
2) In [PATCH 6/6],fix error of "} while (end_scans < start_scans + 20);" to
"} while (end_scans < start_scans + 2);" in wait_two_full_scans().
---
v3->v4:
1) The patch series are readjusted to adapt to these recent changes of break_ksm()
from David Hildenbrand's commits:
https://lore.kernel.org/all/[email protected]/T/#u
2) Some changes of patch itself:
In [patch 2/6], add a check of mm exiting in unshare_zero_pages in case of
unsharing the zero pages whose process is exiting; form a new function
clean_rmap_item_zero_flag(), and add it after stable_tree_search() to fix;
In [patch 3/6], all decreasing actions of zero pages count are put in
clean_rmap_item_zero_flag(), which is more accurate.
3) Add a selftest of unsharing and counting ksm-placed zero pages.
---
v2->v3:
1) Add more descriptive information in cover letter.
2) In [patch 2/5], add more commit log for explaining reasons.
3) In [patch 2/5], fix misuse of break_ksm() in unmerge_ksm_pages():
break_ksm(vma, addr, NULL) -> break_ksm(vma, addr, false);
---
v1->v2:
[patch 4/5] fix build warning, mm/ksm.c:550, misleading indentation; statement
'rmap_item->mm->ksm_zero_pages_sharing--;' is not part of the previous 'if'.
*** BLURB HERE ***
xu xin (6):
ksm: abstract the function try_to_get_old_rmap_item
ksm: support unsharing zero pages placed by KSM
ksm: count all zero pages placed by KSM
ksm: count zero pages for each process
ksm: add zero_pages_sharing documentation
selftest: add testing unsharing and counting ksm zero page
Documentation/admin-guide/mm/ksm.rst | 7 +
fs/proc/base.c | 1 +
include/linux/mm_types.h | 7 +-
mm/ksm.c | 185 +++++++++++++++++-----
tools/testing/selftests/vm/ksm_functional_tests.c | 96 ++++++++++-
5 files changed, 255 insertions(+), 41 deletions(-)
--
2.15.2
On 10.02.23 02:15, [email protected] wrote:
> From: xu xin <[email protected]>
>
Hi,
sorry for the late follow-up. Still wrapping my head around this and
possible alternatives. I hope we'll get some comments from others as
well about the basic approach.
> The core idea of this patch set is to enable users to perceive the number of any
> pages merged by KSM, regardless of whether use_zero_page switch has been turned
> on, so that users can know how much free memory increase is really due to their
> madvise(MERGEABLE) actions. But the problem is, when enabling use_zero_pages,
> all empty pages will be merged with kernel zero pages instead of with each
> other as use_zero_pages is disabled, and then these zero-pages are no longer
> monitored by KSM.
>
> The motivations for me to do this contains three points:
>
> 1) MADV_UNMERGEABLE and other ways to trigger unsharing will *not*
> unshare the shared zeropage as placed by KSM (which is against the
> MADV_UNMERGEABLE documentation at least); see the link:
> https://lore.kernel.org/lkml/[email protected]/
>
> 2) We cannot know how many pages are zero pages placed by KSM when
> enabling use_zero_pages, which hides the critical information about
> how much actual memory are really saved by KSM. Knowing how many
> ksm-placed zero pages are helpful for user to use the policy of madvise
> (MERGEABLE) better because they can see the actual profit brought by KSM.
>
> 3) The zero pages placed-by KSM are different from those initial empty page
> (filled with zeros) which are never touched by applications. The former
> is active-merged by KSM while the later have never consume actual memory.
>
I agree with all of the above, but it's still unclear to me if there is
a real downside to a simpler approach:
(1) Tracking the shared zeropages. That would be fairly easy: whenever
we map/unmap a shared zeropage, we simply update the counter.
(2) Unmerging all shared zeropages inside the VMAs during
MADV_UNMERGEABLE.
(3) Documenting that MADV_UNMERGEABLE will also unmerge the shared
zeropage when toggle xy is flipped.
It's certainly simpler and doesn't rely on the rmap item. See below.
> use_zero_pages is useful, not only because of cache colouring as described
> in doc, but also because use_zero_pages can accelerate merging empty pages
> when there are plenty of empty pages (full of zeros) as the time of
> page-by-page comparisons (unstable_tree_search_insert) is saved. So we hope to
> implement the support for ksm zero page tracking without affecting the feature
> of use_zero_pages.
>
> Zero pages may be the most common merged pages in actual environment(not only VM but
> also including other application like containers). Enabling use_zero_pages in the
> environment with plenty of empty pages(full of zeros) will be very useful. Users and
> app developer can also benefit from knowing the proportion of zero pages in all
> merged pages to optimize applications.
>
I agree with that point, especially after I read in a paper that KSM
applied to some applications mainly deduplicates pages filled with 0s.
So it seems like a reasonable thing to optimize for.
> With the patch series, we can both unshare zero-pages(KSM-placed) accurately
> and count ksm zero pages with enabling use_zero_pages.
The problem with this approach I see is that it fundamentally relies on
the rmap/stable-tree to detect whether a zeropage was placed or not.
I was wondering, why we even need an rmap item *at all* anymore. Why
can't we place the shared zeropage an call it a day (remove the rmap
item)? Once we placed a shared zeropage, the next KSM scan should better
just ignore it, it's already deduplicated.
So if most pages we deduplicate are shared zeropages, it would be quite
interesting to reduce the memory overhead and avoid rmap items, instead
of building new functionality on top of it?
If we'd really want to identify whether a zeropage was deduplciated by
KSM, we could try storing that information inside the PTE instead of
inside the RMAP. Then, we could directly adjust the counter when zapping
the shared zeropage or during MADV_DONTNEED/when unmerging.
Eventually, we could simply say that
* !pte_dirty(): zeropage placed during fault
* pte_dirty(): zeropage placed by KSM
Then it would also be easy to adjust counters and unmerge. We'd limit
this handling to known-working architectures initially (spec64 still has
the issue that pte_mkdirty() will set a pte writable ... and my patch to
fix that was not merged yet). We'd have to double-check all
pte_mkdirty/pte_mkclean() callsites.
--
Thanks,
David / dhildenb
On Mon, 13 Mar 2023 14:03:33 +0100
David Hildenbrand <[email protected]> wrote:
> On 10.02.23 02:15, [email protected] wrote:
> > From: xu xin <[email protected]>
> >
>
> Hi,
>
> sorry for the late follow-up. Still wrapping my head around this and
> possible alternatives. I hope we'll get some comments from others as
> well about the basic approach.
>
> > The core idea of this patch set is to enable users to perceive the number of any
> > pages merged by KSM, regardless of whether use_zero_page switch has been turned
> > on, so that users can know how much free memory increase is really due to their
> > madvise(MERGEABLE) actions. But the problem is, when enabling use_zero_pages,
> > all empty pages will be merged with kernel zero pages instead of with each
> > other as use_zero_pages is disabled, and then these zero-pages are no longer
> > monitored by KSM.
> >
> > The motivations for me to do this contains three points:
> >
> > 1) MADV_UNMERGEABLE and other ways to trigger unsharing will *not*
> > unshare the shared zeropage as placed by KSM (which is against the
> > MADV_UNMERGEABLE documentation at least); see the link:
> > https://lore.kernel.org/lkml/[email protected]/
> >
> > 2) We cannot know how many pages are zero pages placed by KSM when
> > enabling use_zero_pages, which hides the critical information about
> > how much actual memory are really saved by KSM. Knowing how many
> > ksm-placed zero pages are helpful for user to use the policy of madvise
> > (MERGEABLE) better because they can see the actual profit brought by KSM.
> >
> > 3) The zero pages placed-by KSM are different from those initial empty page
> > (filled with zeros) which are never touched by applications. The former
> > is active-merged by KSM while the later have never consume actual memory.
> >
>
> I agree with all of the above, but it's still unclear to me if there is
> a real downside to a simpler approach:
>
> (1) Tracking the shared zeropages. That would be fairly easy: whenever
> we map/unmap a shared zeropage, we simply update the counter.
>
> (2) Unmerging all shared zeropages inside the VMAs during
> MADV_UNMERGEABLE.
>
> (3) Documenting that MADV_UNMERGEABLE will also unmerge the shared
> zeropage when toggle xy is flipped.
>
> It's certainly simpler and doesn't rely on the rmap item. See below.
I would surely prefer a simpler approach
>
> > use_zero_pages is useful, not only because of cache colouring as described
> > in doc, but also because use_zero_pages can accelerate merging empty pages
> > when there are plenty of empty pages (full of zeros) as the time of
> > page-by-page comparisons (unstable_tree_search_insert) is saved. So we hope to
> > implement the support for ksm zero page tracking without affecting the feature
> > of use_zero_pages.
> >
> > Zero pages may be the most common merged pages in actual environment(not only VM but
> > also including other application like containers). Enabling use_zero_pages in the
> > environment with plenty of empty pages(full of zeros) will be very useful. Users and
> > app developer can also benefit from knowing the proportion of zero pages in all
> > merged pages to optimize applications.
> >
>
> I agree with that point, especially after I read in a paper that KSM
> applied to some applications mainly deduplicates pages filled with 0s.
> So it seems like a reasonable thing to optimize for.
>
> > With the patch series, we can both unshare zero-pages(KSM-placed) accurately
> > and count ksm zero pages with enabling use_zero_pages.
>
> The problem with this approach I see is that it fundamentally relies on
> the rmap/stable-tree to detect whether a zeropage was placed or not.
>
> I was wondering, why we even need an rmap item *at all* anymore. Why
> can't we place the shared zeropage an call it a day (remove the rmap
> item)? Once we placed a shared zeropage, the next KSM scan should better
> just ignore it, it's already deduplicated.
>
> So if most pages we deduplicate are shared zeropages, it would be quite
> interesting to reduce the memory overhead and avoid rmap items, instead
> of building new functionality on top of it?
>
>
>
> If we'd really want to identify whether a zeropage was deduplciated by
> KSM, we could try storing that information inside the PTE instead of
this is interesting, but needs caution, for the reason you mention below
> inside the RMAP. Then, we could directly adjust the counter when zapping
> the shared zeropage or during MADV_DONTNEED/when unmerging.
>
> Eventually, we could simply say that
> * !pte_dirty(): zeropage placed during fault
> * pte_dirty(): zeropage placed by KSM
>
> Then it would also be easy to adjust counters and unmerge. We'd limit
> this handling to known-working architectures initially (spec64 still has
> the issue that pte_mkdirty() will set a pte writable ... and my patch to
> fix that was not merged yet). We'd have to double-check all
> pte_mkdirty/pte_mkclean() callsites.
this will be... interesting
>
>> If we'd really want to identify whether a zeropage was deduplciated by
>> KSM, we could try storing that information inside the PTE instead of
>
> this is interesting, but needs caution, for the reason you mention below
>
>> inside the RMAP. Then, we could directly adjust the counter when zapping
>> the shared zeropage or during MADV_DONTNEED/when unmerging.
>>
>> Eventually, we could simply say that
>> * !pte_dirty(): zeropage placed during fault
>> * pte_dirty(): zeropage placed by KSM
>>
>> Then it would also be easy to adjust counters and unmerge. We'd limit
>> this handling to known-working architectures initially (spec64 still has
^ I meant sparc64 here. We can (and should) have a testcase that
deduplicates the shared zeropage using KSM and makes sure that writes
properly lead to a write fault.
>> the issue that pte_mkdirty() will set a pte writable ... and my patch to
>> fix that was not merged yet). We'd have to double-check all
>> pte_mkdirty/pte_mkclean() callsites.
>
> this will be... interesting
IIRC, most code that touches the dirty bit makes sure that it operates
on a proper struct page (via vm_normal_folio()).
madvise_free_pte_range() is one such user. But we have to double-check.
--
Thanks,
David / dhildenb
On Fri, 10 Feb 2023 09:15:22 +0800 (CST) <[email protected]> wrote:
> The core idea of this patch set is to enable users to perceive the number of any
> pages merged by KSM, regardless of whether use_zero_page switch has been turned
> on, so that users can know how much free memory increase is really due to their
> madvise(MERGEABLE) actions. But the problem is, when enabling use_zero_pages,
> all empty pages will be merged with kernel zero pages instead of with each
> other as use_zero_pages is disabled, and then these zero-pages are no longer
> monitored by KSM.
We appear to have some outstanding activity on this quite old patchset.
From my notes:
- An unresponded-to question from Claudia:
https://lkml.kernel.org/r/20230307192421.30ab869c@p-imbrenda
- Hoping for overall review from David
- Another query from Claudia, and a response indicating that a v7 is
in the works.
https://lore.kernel.org/all/20230307194320.79373a26@p-imbrenda/T/#u
- Another unresponded-to review query:
https://lkml.kernel.org/r/20230307195119.745d0b46@p-imbrenda
- Another response indicating that a v7 is coming
https://lkml.kernel.org/r/20230307195313.2e21245a@p-imbrenda
So I think I'll drop the v6 series. Please address all these things in
the next version and let's start over.
On 29.03.23 00:38, Andrew Morton wrote:
> On Fri, 10 Feb 2023 09:15:22 +0800 (CST) <[email protected]> wrote:
>
>> The core idea of this patch set is to enable users to perceive the number of any
>> pages merged by KSM, regardless of whether use_zero_page switch has been turned
>> on, so that users can know how much free memory increase is really due to their
>> madvise(MERGEABLE) actions. But the problem is, when enabling use_zero_pages,
>> all empty pages will be merged with kernel zero pages instead of with each
>> other as use_zero_pages is disabled, and then these zero-pages are no longer
>> monitored by KSM.
>
> We appear to have some outstanding activity on this quite old patchset.
> From my notes:
>
> - An unresponded-to question from Claudia:
> https://lkml.kernel.org/r/20230307192421.30ab869c@p-imbrenda
>
> - Hoping for overall review from David
I already shared some feedback in [1]. I think we should try to simplify
this handling, as proposed in that mail. Still waiting for a reply.
[1]
https://lore.kernel.org/all/[email protected]/
--
Thanks,
David / dhildenb
Hi, I'm sorry to reply so late because I was so busy with my job matters recently.
I appreciate David's idea of simplifying the implement of tracking KSM-placed zero pages.
But I'm confused with how to implement that via pte_mkdirty/pte_dirty without affecting
other functions now and in the future.
>
>I already shared some feedback in [1]. I think we should try to simplify
>this handling, as proposed in that mail. Still waiting for a reply.
>
>[1]
>https://lore.kernel.org/all/[email protected]/
I have some questions about using pte_mkdirty to mark KSM-placed zero pages.
(1) Will KSM using pte_mkdirty to mark KSM-placed zero pages collides with the existing
handling of the same pte in other featutes? And in the future, what if there are new
codes also using pte_mkdirty for other goals.
(2) Can the literal meaning of pte_mkdiry represents a pte that points to ksm zero page?
(3) Suppose we use the pte_mkdirty approach, how to update/decline the count of ksm_zero_pages
when upper app writting on the page triggers COW(Copy on Write)? In *mm_fault outside
mm/ksm.c ?
Move the previos message here to reply together.
>The problem with this approach I see is that it fundamentally relies on
>the rmap/stable-tree to detect whether a zeropage was placed or not.
>
>I was wondering, why we even need an rmap item *at all* anymore. Why
>can't we place the shared zeropage an call it a day (remove the rmap
>item)? Once we placed a shared zeropage, the next KSM scan should better
>just ignore it, it's already deduplicated.
The reason is as follows ...
Initially, all scanned pages by ksmd will be assigned a rmap_item storing the page
information and ksm information, which helps ksmd can know every scanned pages' status and
update all counts especialy when COW happens. But since use_zero_pages feature was merged,
the situation changed, ksm zero pages is the only exception of ksm-scanned page without owning
a rmap_item in KSM, which leads to ksmd even don't know the existing of KSM-placed, and thus
causes the problem of our patches aimed to solve.
On 30.03.23 14:06, xu xin wrote:
> Hi, I'm sorry to reply so late because I was so busy with my job matters recently.
>
> I appreciate David's idea of simplifying the implement of tracking KSM-placed zero pages.
> But I'm confused with how to implement that via pte_mkdirty/pte_dirty without affecting
> other functions now and in the future.
No need to worry about too much about the future here :)
>
>>
>> I already shared some feedback in [1]. I think we should try to simplify
>> this handling, as proposed in that mail. Still waiting for a reply.
>>
>> [1]
>> https://lore.kernel.org/all/[email protected]/
>
> I have some questions about using pte_mkdirty to mark KSM-placed zero pages.
>
> (1) Will KSM using pte_mkdirty to mark KSM-placed zero pages collides with the existing
> handling of the same pte in other featutes? And in the future, what if there are new
> codes also using pte_mkdirty for other goals.
So far I am not aware of other users of the dirty bit for the shared zeropage. If ever
required (why?) we could try finding another PTE bit. Or use a completely separate set
of zeropages, if ever really running out of PTE bits.
I selected pte_dirty() because it's available on all architectures and should be unused
on the shared zeropage (always clean).
Until then, we only have to worry about architectures that treat R/O dirty PTEs as writable
(I only know sparc64), maybe a good justification to finally fix sparc64 and identify others.
Again, happy to help here. [1]
>
> (2) Can the literal meaning of pte_mkdiry represents a pte that points to ksm zero page?
I briefly scanned the code. pte_dirty() should mostly not matter for the shared zeropage.
We have to double check (will do as well).
>
> (3) Suppose we use the pte_mkdirty approach, how to update/decline the count of ksm_zero_pages
> when upper app writting on the page triggers COW(Copy on Write)? In *mm_fault outside
> mm/ksm.c ?
yes. Do it synchronously when unmapping the shared zeropage.
diff --git a/mm/memory.c b/mm/memory.c
index f456f3b5049c..78b6c60602dd 100644
--- a/mm/memory.c
+++ b/mm/memory.c
@@ -1351,6 +1351,8 @@ zap_install_uffd_wp_if_needed(struct vm_area_struct *vma,
pte_install_uffd_wp_if_needed(vma, addr, pte, pteval);
}
+#define is_ksm_zero_pte(pte) (is_zero_pfn(pte_pfn(pte)) && pte_dirty(pte))
+
static unsigned long zap_pte_range(struct mmu_gather *tlb,
struct vm_area_struct *vma, pmd_t *pmd,
unsigned long addr, unsigned long end,
@@ -1392,8 +1394,11 @@ static unsigned long zap_pte_range(struct mmu_gather *tlb,
tlb_remove_tlb_entry(tlb, pte, addr);
zap_install_uffd_wp_if_needed(vma, addr, pte, details,
ptent);
- if (unlikely(!page))
+ if (unlikely(!page)) {
+ if (is_ksm_zero_pte(ptent))
+ /* TODO: adjust counter */
continue;
+ }
delay_rmap = 0;
if (!PageAnon(page)) {
@@ -3111,6 +3116,8 @@ static vm_fault_t wp_page_copy(struct vm_fault *vmf)
inc_mm_counter(mm, MM_ANONPAGES);
}
} else {
+ if (is_ksm_zero_pte(orig_pte))
+ /* TODO: adjust counter */
inc_mm_counter(mm, MM_ANONPAGES);
}
flush_cache_page(vma, vmf->address, pte_pfn(vmf->orig_pte));
The nice thing is, if we get it wrong we "only" get wrong counters.
A prototype for that should be fairly simple -- to see what we're missing.
>
>
> Move the previos message here to reply together.
>> The problem with this approach I see is that it fundamentally relies on
>> the rmap/stable-tree to detect whether a zeropage was placed or not.
>>
>> I was wondering, why we even need an rmap item *at all* anymore. Why
>> can't we place the shared zeropage an call it a day (remove the rmap
>> item)? Once we placed a shared zeropage, the next KSM scan should better
>> just ignore it, it's already deduplicated.
>
> The reason is as follows ...
> Initially, all scanned pages by ksmd will be assigned a rmap_item storing the page
> information and ksm information, which helps ksmd can know every scanned pages' status and
> update all counts especialy when COW happens. But since use_zero_pages feature was merged,
> the situation changed, ksm zero pages is the only exception of ksm-scanned page without owning
> a rmap_item in KSM, which leads to ksmd even don't know the existing of KSM-placed, and thus
> causes the problem of our patches aimed to solve.
>
Understood, so per-PTE information would similarly work.
[1] https://lkml.kernel.org/r/[email protected]
--
Thanks,
David / dhildenb
>> The core idea of this patch set is to enable users to perceive the number of any
>> pages merged by KSM, regardless of whether use_zero_page switch has been turned
>> on, so that users can know how much free memory increase is really due to their>
>> madvise(MERGEABLE) actions. But the problem is, when enabling use_zero_pages,
>> all empty pages will be merged with kernel zero pages instead of with each
>> other as use_zero_pages is disabled, and then these zero-pages are no longer
>> monitored by KSM.
>
We have sent the v7 series, so some old codes might be changed, and no need to talk
more.
>We appear to have some outstanding activity on this quite old patchset.
>From my notes:
>
>- An unresponded-to question from Claudia:
> https://lkml.kernel.org/r/20230307192421.30ab869c@p-imbrenda
>
Claudia is right, but the v7 patches don't rely on rmap_items now, so we can skip
this comment.
>- Hoping for overall review from David
>
David's review is great, and we accept his advice on the basic approach in v7 patches
to track the ksm zero pages. and now the v7 patches use pte_dirty to mark the
KSM-placed zere pages. But since pte_dirty is related to architectures, and some
architecture may treat pte_dirty as writable, so we restrict the feature of tracking
ksm zero pages only to the tested and well-working architecture.
>- Another query from Claudia, and a response indicating that a v7 is
> in the works.
> https://lore.kernel.org/all/20230307194320.79373a26@p-imbrenda/T/#u
The v7 series don't changed it there now, then we can skip it.
>
>- Another unresponded-to review query:
> https://lkml.kernel.org/r/20230307195119.745d0b46@p-imbrenda
>
The v7 series have referred to Claudia's review but made a few modifications.
>- Another response indicating that a v7 is coming
> https://lkml.kernel.org/r/20230307195313.2e21245a@p-imbrenda
>
> So I think I'll drop the v6 series. Please address all these things in
> the next version and let's start over.
Yes, the next version is here:
https://lore.kernel.org/lkml/[email protected]/
On Fri, 14 Apr 2023 09:35:07 +0800
xu xin <[email protected]> wrote:
> >> The core idea of this patch set is to enable users to perceive the number of any
> >> pages merged by KSM, regardless of whether use_zero_page switch has been turned
> >> on, so that users can know how much free memory increase is really due to their>
> >> madvise(MERGEABLE) actions. But the problem is, when enabling use_zero_pages,
> >> all empty pages will be merged with kernel zero pages instead of with each
> >> other as use_zero_pages is disabled, and then these zero-pages are no longer
> >> monitored by KSM.
> >
>
> We have sent the v7 series, so some old codes might be changed, and no need to talk
> more.
>
> >We appear to have some outstanding activity on this quite old patchset.
> >From my notes:
> >
> >- An unresponded-to question from Claudia:
> > https://lkml.kernel.org/r/20230307192421.30ab869c@p-imbrenda
> >
>
> Claudia is right, but the v7 patches don't rely on rmap_items now, so we can skip
> this comment.
>
> >- Hoping for overall review from David
> >
>
> David's review is great, and we accept his advice on the basic approach in v7 patches
> to track the ksm zero pages. and now the v7 patches use pte_dirty to mark the
> KSM-placed zere pages. But since pte_dirty is related to architectures, and some
> architecture may treat pte_dirty as writable, so we restrict the feature of tracking
> ksm zero pages only to the tested and well-working architecture.
>
> >- Another query from Claudia, and a response indicating that a v7 is
> > in the works.
> > https://lore.kernel.org/all/20230307194320.79373a26@p-imbrenda/T/#u
>
> The v7 series don't changed it there now, then we can skip it.
>
> >
> >- Another unresponded-to review query:
> > https://lkml.kernel.org/r/20230307195119.745d0b46@p-imbrenda
> >
>
> The v7 series have referred to Claudia's review but made a few modifications.
I would just like to point out that my name is Claudio, not
Claudia. (this goes to Andrew as well)
thanks
>
> >- Another response indicating that a v7 is coming
> > https://lkml.kernel.org/r/20230307195313.2e21245a@p-imbrenda
> >
> > So I think I'll drop the v6 series. Please address all these things in
> > the next version and let's start over.
>
> Yes, the next version is here:
> https://lore.kernel.org/lkml/[email protected]/
>
>