On Wed, May 27, 2020 at 07:00:30PM +0200, Vlastimil Babka wrote: > On 5/26/20 5:45 PM, Roman Gushchin wrote: > > On Tue, May 26, 2020 at 05:24:46PM +0200, Vlastimil Babka wrote: > >> 1 << 20 ? > >> > >> Anyway I was getting this: > >> not ok 1 test_kmem_basic > >> ok 2 test_kmem_memcg_deletion > >> ok 3 test_kmem_proc_kpagecgroup > >> not ok 4 test_kmem_kernel_stacks > >> ok 5 test_kmem_dead_cgroups > >> > >> Adding some debugging into kmem_basic I found I get memory.stat == 0 at this > >> point thus it fails the fixed test (otherwise it was failing the <= 0 test after > >> writing to memory.high). But it's just a VM spinned by virtme which has a very > >> simple init, so perhaps things are not as initialized as expected. > > > > Hm, it's strange, do you have any values in memory.stat::slab for any cgroups? > > Or can you send me your config (and kvm setup), I'll take a look. > > Config is attached, KVM setup is just running virtme [1] on the git gree where I > compiled the kernel: > > virtme-run --mods=auto --kdir /path/to/linux.git/ Thanks! So, test_kmem_kernel_stacks fails because there is not enough memory in your setup: it tries to spawn 1000 threads, and virtme-run sets the total memory in 100M, which is not enough. Adding --memory 4G option makes the test pass. > > So there's only the cgroup the test creates, and the memry.stat::slab is zero > after alloc_dcache(). Although I can see by strace that it does all those > stat()'s. Also /proc/slabinfo also doesn't seem to be increasing number of > dentries. Could be that because root fs is 9p in virtme? The basic test seems to fail because of 9p. It also fails on the unpatched kernel, so it's definitely not a regression. So, maybe it's better to allocate kernel memory in the test using a different method? I'm open for any ideas here. Thanks!
