Comment # 33 on bug 1159882 from Michal Hocko

(In reply to Robert Delahunt from comment #27)
> I had reinstalled OpenSUSE LEAP 15.2 using the DVD but with network enabled,
> so what I should've gotten was a fresh installation of the most current
> stable OpenSUSE LEAP 15.2.
> 
> VMSTAT information as requested:
> 
> http://www.puresimplicity.net/~delahunt/vmstat/swapon/
> 
> http://www.puresimplicity.net/~delahunt/vmstat/swapoff/
> 
> Basically, I had reinstalled OpenSUSE LEAP 15.2 with the LUKS-contained LVM
> of /dev/system/home and /dev/system/swap but I had deleted the LV of swap
> and ran the system without swap.  So the swapoff is a recording of vmstat
> while I was doing
> 
> dd if=/dev/zero of=/dev/sdb bs=4K status=progress
> 
> and the swapon directory is after I went back into the partitioner,
> recreated the swap LV, turned swap on, then ran the dd command above all
> over again.

I have looked at swapon data.
                First vmstat    Last vmstat[diff]
pgscan_direct   2383            0
pgscan_kswapd   14565113        424280
pgsteal_kswapd  14513308        423192

No direct reclaim, so kswapd was able to cope with the allocation pace. The
overall reclaim efficiency is nice as well (99%) and the reclaim itself has
freed 1.6G worth of memory

pgalloc_dma32   2334299         467232
pgalloc_normal  24091786        3564456

while 15.7G of memory was requested during that time period.

pswpin          0               0
pswpout         0               11842

No memory has been swapped in while 46M has been swapped out. This on its own
doesn't sound overly excessive. I would be much more worried if pswpin was high
because that would suggest that memory actively in use has been swapped out and
so the owner would see larger latencies on refault.

workingset_activate     86      41
workingset_refault      10237   141
workingset_restore      0       0

These are stats for disk based page cache refaults. workingset_refault will
tell us how many page cache pages have been reclaimed and then faulted back in
again. 141 pages is really minuscule. workingset_activate tells us how many
pages were reclaimed recently so we should consider them active.
workingset_restore will tell us that the refault is happening on a previously
active page. All in all not much of a refault activity. If there is enough
clean page cache then we shouldn't swap at all.

There are three jumps in swapout
vmstat.1600702573:pswpout 0
vmstat.1600702574:pswpout 2448
[...]
vmstat.1600702577:pswpout 5555
vmstat.1600702578:pswpout 10605
vmstat.1600702579:pswpout 11330

The biggest one swapped out 5050 withing one second.
                 vmstat.1600702577    1600702578 [diff]
nr_active_anon          373934        -3376
nr_active_file          131158        0
nr_inactive_anon        48441         8556
nr_inactive_file        3288371       1169
nr_dirty                632308        28

There is plenty of inactive pagecache. A large part is dirty but there should
be still a lot of clean page cache to reclaim. The file inactive list is
clearly not low on the global level.

workingset_refault      10281          0

no refaults detected so the heuristic from 2c012a4ad1a2 shouldn't trigger.

These are all global numbers. Picture would be quite different if memory
cgroups were deployed though. I have asked earlier for the behavior with
cgroup_disable=memory on the kernel command line parameter. See comment 12 for
more information.