>> From: xu xin <xu.xin16@xxxxxxxxxx> >> >> 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 comparisons (unstable_tree_search_insert) is saved. >> >> But there is something to improve, that 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 >> managed and monitor by KSM, which leads to two issues at least: > >Sorry, but I'm struggling to understand what real value this patchset >offers. > >> 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/4a3daba6-18f9-d252-697c-197f65578c44@xxxxxxxxxx/ > >Is that causing users any real-world problem? If not, just change the >documentation? > >> 2) we cannot know how many pages are zero pages placed by KSM when >> enabling use_zero_pages, which leads to KSM not being transparent >> with all actual merged pages by KSM. > >Why is this a problem? > >A full description of the real-world end-user operational benefits of >these changes would help, please. > 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. The motivation for me to do this is that when I do an application optimization of KSM on embedded Linux for 5G platform, I find that ksm_merging_pages of some process becomes very small(but used to be large), which led me to think that there was any problem with the application KSM-madvise strategy, but in fact, it was only because use_zero_pages is on.
