On Tue, Aug 01, 2023 at 05:55:29PM +0300, gudkov.and...@huawei.com wrote: > Hmmm, such underestimation looks strange to me. I am willing to test > page-sampling and see whether its quality can be improved. Do you have > any specific suggestions on the application to use as a workload?
I could have had a wrong impression here, sorry. I played again with the page sampling approach, and that's actually pretty decent.. I had that impression probably based on the fact that by default we chose 2 pages out of 1000-ish (consider workloads having 100-ish memory updates where no sample page falls into it), and I do remember in some cases of my test setups quite some time ago, it shows totally wrong numbers. But maybe I had a wrong test, or wrong memory. Now thinking about it, for random/seq on not so small memory ranges, that seems to all work. For very small ones spread over it goes to the random case. > > If it turns out that page-sampling is not an option, then performance > impact of the dirty-bitmap must be improved somehow. Maybe it makes > sense to split memory into 4GiB chunks and measure dirty page rate > independently for each of the chunks (without enabling page > protections for memory outside of the currently processed chunk). > But the downsides are that 1) total measurement time will increase > proportionally by number of chunks 2) dirty page rate will be > overestimated. > > But actually I am still hoping on page sampling. Since my goal is to > roughly predict what can be migrated and what cannot be, I would prefer > to keep predictor as lite as possible, even at the cost of > (overestimation) error. Yes I also hope that works as you said. Thanks, -- Peter Xu
