On (07/24/18 10:03), Minchan Kim wrote: > On Mon, Jul 23, 2018 at 02:29:32PM +0200, Tino Lehnig wrote: > > Hello, > > > > after enabling the writeback feature in zram, I encountered the kernel bug > > below with heavy swap utilization. There is one specific workload that > > triggers the bug reliably and that is running Windows in KVM while > > overcommitting memory. The Windows VMs would fill all allocated memory with > > zero pages while booting. A few seconds after the host hits zram swap, the > > console on the host is flooded with the bug message. A few more seconds > > later I also encountered filesystem errors on the host causing the root > > filesystem to be mounted read-only. The filesystem errors do not occur when > > leaving RAM available for the host OS by limiting physical memory of the > > QEMU processes via cgroups. > > > > I started three KVM instances with the following commands in my tests. Any > > Windows ISO or disk image can be used. Less instances and smaller allocated > > memory will also trigger the bug as long as swapping occurs. The type of > > writeback device does not seem to matter. I have tried a SATA SSD and an > > NVMe Optane drive so far. My test machine has 256 GB of RAM and one CPU. I > > saw the same behavior on another machine with two CPUs and 128 GB of RAM. > > > > The bug does not occur when using zram as swap without "backing_dev" being > > set, but I had even more severe problems when running the same test on > > Ubuntu Kernels 4.15 and 4.17. Regardless of the writeback feature being used > > or not, the host would eventually lock up entirely when swap is in use on > > zram. The lockups may not be related directly to zram though and were > > apparently fixed in 4.18. I had absolutely no problems on Ubuntu Kernel 4.13 > > either, before the writeback feature was introduced. > > We didn't release v4.18 yet. Could you say what kernel tree/what version > you used? > > Now I don't have enough time to dig in. > > Sergey, I really appreciate if you could have availabe time to look into. > Anyway, I could try to see it asap if Sergey is not available. > No worry.
Interesting case. Will take me several days to get to it. Sorry, quite busy at the moment. -ss