Re: [PATCH] mm: introduce clear all vm events counters

On 2021-03-02 21:26, Johannes Weiner wrote:

On Tue, Mar 02, 2021 at 04:00:34PM +0530, pintu@codeaurora.org wrote:

quoted

On 2021-03-01 20:41, Johannes Weiner wrote:

quoted

On Mon, Mar 01, 2021 at 04:19:26PM +0530, Pintu Kumar wrote:

quoted

At times there is a need to regularly monitor vm counters while we
reproduce some issue, or it could be as simple as gathering some
system
statistics when we run some scenario and every time we like to start
from
beginning.
The current steps are:
Dump /proc/vmstat
Run some scenario
Dump /proc/vmstat again
Generate some data or graph
reboot and repeat again

You can subtract the first vmstat dump from the second to get the
event delta for the scenario run. That's what I do, and I'd assume
most people are doing. Am I missing something?

Thanks so much for your comments.
Yes in most cases it works.

But I guess there are sometimes where we need to compare with fresh 
data
(just like reboot) at least for some of the counters.
Suppose we wanted to monitor pgalloc_normal and pgfree.

Hopefully these would already be balanced out pretty well before you
run a test, or there is a risk that whatever outstanding allocations
there are can cause a large number of frees during your test that
don't match up to your recorded allocation events. Resetting to zero
doesn't eliminate the risk of such background noise.

quoted

Or, suppose we want to monitor until the field becomes non-zero..
Or, how certain values are changing compared to fresh reboot.
Or, suppose we want to reset all counters after boot and start 
capturing
fresh stats.

Again, there simply is no mathematical difference between

	reset events to 0
	run test
	look at events - 0

and

	read events baseline
	run test
	look at events - baseline

quoted

Some of the counters could be growing too large and too fast. Will 
there be
chances of overflow ?
Then resetting using this could help without rebooting.

Overflows are just a fact of life on 32 bit systems. However, they can
also be trivially handled - you can always subtract a ulong start
state from a ulong end state and get a reliable delta of up to 2^32
events, whether the end state has overflowed or not.

The bottom line is that the benefit of this patch adds a minor
convenience for something that can already be done in userspace. But
the downside is that there would be one more possible source of noise
for kernel developers to consider when looking at a bug report. Plus
the extra code and user interface that need to be maintained.

I don't think we should merge this patch.

Okay no problem.Thank you so much for your review and feedback.
Yes I agree the benefits are minor but I thought might be useful for 
someone somewhere.
I worked on it and found it easy and convinient and thus proposed it.
If others feel not important I am okay to drop it.

Thanks once again to all who helped to review it.