Re: [PATCH v6 0/6] ksm: support tracking KSM-placed zero-pages

[xu xin]

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/9d7a8be3-ee9e-3492-841b-a0af9952ef36@xxxxxxxxxx/

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.