From: pintu@codeaurora.org
To: Johannes Weiner <hannes@cmpxchg.org>
Cc: linux-kernel@vger.kernel.org, akpm@linux-foundation.org,
linux-mm@kvack.org, linux-fsdevel@vger.kernel.org,
linux-doc@vger.kernel.org, jaewon31.kim@samsung.com,
yuzhao@google.com, shakeelb@google.com, guro@fb.com,
mchehab+huawei@kernel.org, xi.fengfei@h3c.com,
lokeshgidra@google.com, nigupta@nvidia.com, famzheng@amazon.com,
andrew.a.klychkov@gmail.com, bigeasy@linutronix.de,
ping.ping@gmail.com, vbabka@suse.cz, yzaikin@google.com,
keescook@chromium.org, mcgrof@kernel.org, corbet@lwn.net,
pintu.ping@gmail.com
Subject: Re: [PATCH] mm: introduce clear all vm events counters
Date: Tue, 02 Mar 2021 16:00:34 +0530 [thread overview]
Message-ID: <419bb403c33b7e48291972df938d0cae@codeaurora.org> (raw)
In-Reply-To: <YD0EOyW3pZXDnuuJ@cmpxchg.org>
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.
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.
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.
Suppose system came back from hibernation, and we want to reset all
counters again (to capture fresh data) ?
Here I am sharing one output (from qemu-arm32 with 256MB RAM) just to
indicate what could be changed:
Scenario: Generate OOM kill case and check oom_kill counter
BEFORE AFTER proc/vmstat
------ ------ -----------------------
49991 49916 nr_free_pages
4467 4481 nr_zone_inactive_anon
68 68 nr_zone_active_anon
3189 3067 nr_zone_inactive_file
223 444 nr_zone_active_file
0 0 nr_zone_unevictable
122 136 nr_zone_write_pending
0 0 nr_mlock
139 139 nr_page_table_pages
0 0 nr_bounce
0 0 nr_zspages
4032 4032 nr_free_cma
4467 4481 nr_inactive_anon
68 68 nr_active_anon
3189 3067 nr_inactive_file
223 444 nr_active_file
0 0 nr_unevictable
1177 1178 nr_slab_reclaimable
1889 1889 nr_slab_unreclaimable
0 0 nr_isolated_anon
0 0 nr_isolated_file
176 163 workingset_nodes
0 0 workingset_refault_anon
3295 3369 workingset_refault_file
0 0 workingset_activate_anon
4 4 workingset_activate_file
0 0 workingset_restore_anon
4 4 workingset_restore_file
0 0 workingset_nodereclaim
4436 4436 nr_anon_pages
2636 2678 nr_mapped
3559 3645 nr_file_pages
122 136 nr_dirty
0 0 nr_writeback
0 0 nr_writeback_temp
126 126 nr_shmem
0 0 nr_shmem_hugepages
0 0 nr_shmem_pmdmapped
0 0 nr_file_hugepages
0 0 nr_file_pmdmapped
0 0 nr_anon_transparent_hugepages
1 1 nr_vmscan_write
1 1 nr_vmscan_immediate_reclaim
1024 1038 nr_dirtied
902 902 nr_written
0 0 nr_kernel_misc_reclaimable
0 0 nr_foll_pin_acquired
0 0 nr_foll_pin_released
616 616 nr_kernel_stack
10529 10533 nr_dirty_threshold
5258 5260 nr_dirty_background_threshold
50714 256 pgpgin
3932 16 pgpgout
0 0 pswpin
0 0 pswpout
86828 122 pgalloc_normal
0 0 pgalloc_movable
0 0 allocstall_normal
22 0 allocstall_movable
0 0 pgskip_normal
0 0 pgskip_movable
139594 34 pgfree
4998 155 pgactivate
5738 0 pgdeactivate
0 0 pglazyfree
82113 122 pgfault
374 2 pgmajfault
0 0 pglazyfreed
7695 0 pgrefill
2718 20 pgreuse
9261 0 pgsteal_kswapd
173 0 pgsteal_direct
12627 0 pgscan_kswapd
283 0 pgscan_direct
2 0 pgscan_direct_throttle
0 0 pgscan_anon
12910 0 pgscan_file
0 0 pgsteal_anon
9434 0 pgsteal_file
0 0 pginodesteal
7008 0 slabs_scanned
109 0 kswapd_inodesteal
16 0 kswapd_low_wmark_hit_quickly
24 0 kswapd_high_wmark_hit_quickly
43 0 pageoutrun
1 0 pgrotated
0 0 drop_pagecache
0 0 drop_slab
1 0 oom_kill
1210 0 pgmigrate_success
0 0 pgmigrate_fail
0 0 thp_migration_success
0 0 thp_migration_fail
0 0 thp_migration_split
1509 0 compact_migrate_scanned
9015 0 compact_free_scanned
3911 0 compact_isolated
0 0 compact_stall
0 0 compact_fail
0 0 compact_success
3 0 compact_daemon_wake
1509 0 compact_daemon_migrate_scanned
9015 0 compact_daemon_free_scanned
0 0 unevictable_pgs_culled
0 0 unevictable_pgs_scanned
0 0 unevictable_pgs_rescued
0 0 unevictable_pgs_mlocked
0 0 unevictable_pgs_munlocked
0 0 unevictable_pgs_cleared
0 0 unevictable_pgs_stranded
0 0 balloon_inflate
0 0 balloon_deflate
0 0 balloon_migrate
0 0 swap_ra
0 0 swap_ra_hit
0 0 nr_unstable
Thanks,
Pintu
next prev parent reply other threads:[~2021-03-02 18:08 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-03-01 10:49 [PATCH] mm: introduce clear all vm events counters Pintu Kumar
2021-03-01 12:13 ` Matthew Wilcox
2021-03-01 13:55 ` pintu
2021-03-01 15:11 ` Johannes Weiner
2021-03-02 10:30 ` pintu [this message]
2021-03-02 15:56 ` Johannes Weiner
2021-03-03 12:25 ` pintu
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=419bb403c33b7e48291972df938d0cae@codeaurora.org \
--to=pintu@codeaurora.org \
--cc=akpm@linux-foundation.org \
--cc=andrew.a.klychkov@gmail.com \
--cc=bigeasy@linutronix.de \
--cc=corbet@lwn.net \
--cc=famzheng@amazon.com \
--cc=guro@fb.com \
--cc=hannes@cmpxchg.org \
--cc=jaewon31.kim@samsung.com \
--cc=keescook@chromium.org \
--cc=linux-doc@vger.kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=lokeshgidra@google.com \
--cc=mcgrof@kernel.org \
--cc=mchehab+huawei@kernel.org \
--cc=nigupta@nvidia.com \
--cc=ping.ping@gmail.com \
--cc=pintu.ping@gmail.com \
--cc=shakeelb@google.com \
--cc=vbabka@suse.cz \
--cc=xi.fengfei@h3c.com \
--cc=yuzhao@google.com \
--cc=yzaikin@google.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).