lkml.org 
[lkml]   [2022]   [Oct]   [10]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH v2 0/5] ksm: support tracking KSM-placed zero-pages
On Mon, 10 Oct 2022 12:08:34 +0000
xu xin <xu.xin.sc@gmail.com> wrote:

> 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.

interesting, this is some useful information that you could have written
in the cover letter and/or commit messages, to explain why you are
proposing these changes :)

>
> >
> >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 interesting information, which you could also have written in the
cover letter and/or commit messages

> 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.
>

\
 
 \ /
  Last update: 2022-10-10 15:44    [W:0.132 / U:0.464 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site