This issue was introduced with the massive kernel configurations changes
between mainline kernels 4.7-rc4 and 4.7-rc5. While I have been working
on it for a couple of weeks, I was never able to isolate the exact
kernel configuration change cause. I am compiling a kernel now (4.8-rc7)
reverting this change to test. This attachment has some tools I made to
very very simply show the issue.

If I look at linux/Documentation/workqueue.txt and do:

echo workqueue:workqueue_queue_work >


cat /sys/kernel/debug/tracing/trace_pipe > out.txt

with the issue, I get somwhere between 10,000 and 20,000 occurances of
memcg_kmem_cache_create_func in the file (using my simple test method).
Without the issue, I get 21, and an overall file size about 50 times
smaller, for otherwise similar conditions. i.e. with the issue this
stuff seems to go nuts.

** Attachment added: "Some tools to simply show the issue"

You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.

  4.8 regression: SLAB is being used instead of SLUB

Status in linux package in Ubuntu:
  Fix Committed
Status in linux source package in Yakkety:
  Fix Committed

Bug description:
  We're seeing hundreds of kernel worker threads being spawned with some
  actions, for example, after booting the desktop and hutting the
  brightness keys causes this.  On investigation, this occurs when
  CONFIG_SLAB is being used.

  1. Ubuntu traditionally uses CONFIG_SLUB, so we should use that instead of 
CONFIG_SLAB (why was it changed for Yakkety?)
  2. With CONFIG_SLUB I cannot reproduce the issue of the hundreds for worker 
  3 CONFIG_SLUB seems more performant on the boot too over SLAB.

  Please re-enable the CONFIG_SLUB allocator as per the 4.4. Xenial

To manage notifications about this bug go to:

Mailing list:
Post to     :
Unsubscribe :
More help   :

Reply via email to