From: xu xin <xu.xin.sc@gmail.com>
To: imbrenda@linux.ibm.com
Cc: akpm@linux-foundation.org, david@redhat.com,
jiang.xuexin@zte.com.cn, linux-kernel@vger.kernel.org,
linux-mm@kvack.org, ran.xiaokai@zte.com.cn, xu.xin.sc@gmail.com,
xu.xin16@zte.com.cn, yang.yang29@zte.com.cn
Subject: Re: [PATCH v2 0/5] ksm: support tracking KSM-placed zero-pages
Date: Mon, 10 Oct 2022 12:08:34 +0000 [thread overview]
Message-ID: <20221010120834.318840-1-xu.xin16@zte.com.cn> (raw)
In-Reply-To: <20221010112413.219dc989@p-imbrenda>
Hello, Thanks for your reply.
>
>why are you trying so hard to fix something that is not broken?
Actually, it breaks the definition of unmerge, though it's usually not a big
problem.
>
>can't you just avoid using use_zero_pages?
use_zero_pages is good, not just 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 comparision
(unstable_tree_search_insert) is saved.
>
>why is it so important to know how many zero pages have been merged?
>and why do you want to unmerge them?
Zero pages may be the most common merged pages in actual environment(not only VM but
also including other application like containers). Sometimes customers (app developers)
are very interested in how many non-zero-pages are actually merged in their apps.
>
>the important thing is that the sysadmin knows how much memory would be
>needed to do the unmerge, and that information is already there.
>
I think it's about chicken-and-egg problem.
Anyway, thanks for your reply.
next prev parent reply other threads:[~2022-10-10 12:08 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-10-09 2:18 xu.xin.sc
2022-10-09 2:19 ` [PATCH v2 1/5] ksm: abstract the function try_to_get_old_rmap_item xu.xin.sc
2022-10-09 2:23 ` [PATCH v2 2/5] ksm: support unsharing zero pages placed by KSM xu.xin.sc
2022-10-09 2:23 ` [PATCH v2 3/5] ksm: count all " xu.xin.sc
2022-10-09 2:23 ` [PATCH v2 4/5] ksm: count zero pages for each process xu.xin.sc
2022-10-09 2:23 ` [PATCH v2 5/5] ksm: add zero_pages_sharing documentation xu.xin.sc
2022-10-10 9:24 ` [PATCH v2 0/5] ksm: support tracking KSM-placed zero-pages Claudio Imbrenda
2022-10-10 12:08 ` xu xin [this message]
2022-10-10 13:42 ` Claudio Imbrenda
2022-10-11 2:31 ` xu xin
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20221010120834.318840-1-xu.xin16@zte.com.cn \
--to=xu.xin.sc@gmail.com \
--cc=akpm@linux-foundation.org \
--cc=david@redhat.com \
--cc=imbrenda@linux.ibm.com \
--cc=jiang.xuexin@zte.com.cn \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=ran.xiaokai@zte.com.cn \
--cc=xu.xin16@zte.com.cn \
--cc=yang.yang29@zte.com.cn \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox