On Tue, 4 Jun 2024 11:18:25 -0600 Yu Zhao <yuzhao@xxxxxxxxxx> wrote: > Hi Erhard, > > If it's not too much trouble, could you "grep nr_zspages /proc/vmstat" > on kernels before and after the bad commit? It'd be great if you could > run the grep command right before the OOM kills. > > The overall internal fragmentation of multiple zsmalloc pools might be > higher than a single one. I suspect this might be the cause. > > Thank you. I used watch -n1 'grep nr_zspages /proc/vmstat' to get the readings and repeated this 3 times to check whether the reported values differ much. Bad commit was b8cf32dc6e8c75b712cbf638e0fd210101c22f17 "mm: zswap: multiple zpools support", next commit in git log after the bad one would be 42c06a0e8ebe95b81e5fb41c6556ff22d9255b0c "mm: kill frontswap". With this kernel I got 2440, 2337, 3245 as nr_zspages and the kswapd0: page allocation error. Commit in git log before the bad one would be bfaa4a0ce1bbc1b2b67de7e4c2e1679495f7b905 "scsi: gvp11: Remove unused gvp11_setup() function". With this kernel I got 25537, 11321, 16087 as nr_zspages and the OOM reaper. Tomorrow I could also check the .config changes Vlastimil suggested (CONFIG_SLAB_MERGE_DEFAULT=y, no CONFIG_RANDOM_KMALLOC_CACHES) and report back if that's of interest. Regards, Erhard
