On Thu, Dec 26, 2019 at 09:41:30PM +0000, Christopher Lameter wrote: > On Mon, 23 Dec 2019, Andrew Morton wrote: > > > Guys, did we make recent changes in this area? > > Yes the cgroup folks did. f.e. > > commit 04f768a39d55967246c002aa66b407b3bfdd8269 > Author: Waiman Long <longman@xxxxxxxxxx> > Date: Mon Sep 23 15:33:46 2019 -0700 > > mm, slab: extend slab/shrink to shrink all memcg caches I'd be surprised if the issue is caused by using of this very new interface. But it would be an easy thing... > > Currently, a value of '1" is written to /sys/kernel/slab/<slab>/shrink > file to shrink the slab by flushing out all the per-cpu slabs and free > slabs in partial lists. This can be useful to squeeze out a bit more > memory under extreme condition as well as making the active object > counts > in /proc/slabinfo more accurate. > > This usually applies only to the root caches, as the SLUB_ME > Otherwise I bet on some race around s->kobj.state_in_sysfs . It interesting that it reproduces on a single cpu i386 machine. I really wonder what makes it different. Dennis, can you, please, insert some debug printing into sysfs_slab_remove_workfn()? I wonder if it's really called twice and where exactly it panics? Thanks!
