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:
Status in linux source package in Yakkety:
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: https://launchpad.net/~kernel-packages
Post to : email@example.com
Unsubscribe : https://launchpad.net/~kernel-packages
More help : https://help.launchpad.net/ListHelp