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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:   Wed, 03 Mar 2021 17:55:38 +0530
From:   pintu@...eaurora.org
To:     Johannes Weiner <hannes@...xchg.org>
Cc:     linux-kernel@...r.kernel.org, akpm@...ux-foundation.org,
        linux-mm@...ck.org, linux-fsdevel@...r.kernel.org,
        linux-doc@...r.kernel.org, jaewon31.kim@...sung.com,
        yuzhao@...gle.com, shakeelb@...gle.com, guro@...com,
        mchehab+huawei@...nel.org, xi.fengfei@....com,
        lokeshgidra@...gle.com, nigupta@...dia.com, famzheng@...zon.com,
        andrew.a.klychkov@...il.com, bigeasy@...utronix.de,
        ping.ping@...il.com, vbabka@...e.cz, yzaikin@...gle.com,
        keescook@...omium.org, mcgrof@...nel.org, corbet@....net,
        pintu.ping@...il.com
Subject: 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@...eaurora.org wrote:
>> On 2021-03-01 20:41, Johannes Weiner wrote:
>> > On Mon, Mar 01, 2021 at 04:19:26PM +0530, Pintu Kumar wrote:
>> > > 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.
> 
>> 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
> 
>> 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.