Comment # 8 on bug 1013629 from Michal Hocko

(In reply to Howard Guo from comment #6)
> Created attachment 705814 [details]
> experiment-1
> 
[...]
> The files in experiment-1.tgz are captured from the following sequence of
> events:
> - Leave the memory consuming daemons running, so that system memory usage is
> ~ 250MB/485MB.
> - Observe that kswapd is not using 100% CPU.
> - Run "zypper dup" and observe that kswapd begins consuming 100% CPU (at
> 1481275470)
> - Zypper soon finishes (no update to install), and kswapd stops consuming
> 100% CPU.

Yes, the only reclaim activity I can see is between
            base            diff 
pgscan_kswapd_dma32     523489          9743
pgscan_kswapd_dma       20067723            233
pgsteal_kswapd_dma32    434292          6407
pgsteal_kswapd_dma      11695           129
kswapd_inodesteal       147565          382
kswapd_high_wmark_hit_quickly   16706938        34227

Apart from quite a large kswapd_high_wmark_hit_quickly nothing really
suspicious here. It suggests that the kswapd wanted to go to sleep but
it couldn't because there was still some work to be done.

> According to the first experiment, kswapd0 does not always stay at 100%
> memory usage after memory is pressured. Three days ago I observed that
> kswapd0 stayed at 100% CPU usage even after memory pressure is relieved.

I would be interested in vmstat from those runs.