> >>>> 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. >> >> OK, thanks. >> >>> 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. >> >> Please expand on the above motivation and experience, and include it in >> the [0/n] changelog. But let's leave it a few days to see if there's >> additional reviewer input. >> > >I just posted a selftest: > >https://lore.kernel.org/all/20221021101141.84170-5-david@xxxxxxxxxx/T/#u > >That could (should) be extended to test if unmerging works as expected. > Yes. As you said, these selftests can be extended to test if unsharing KSM-placed zero pages works as expected, and I'm happy to do the extending after they are merged. > >Having that said, I think we really want a second pair of (KSM-expert) >eyes on these changes before moving forward with them. OK, don't worry. Let it be reviewed for a more time, so as to absorb more views later. If necessary, I will resend the patches to adjust to break_ksm()'s changes.
