> Are you sure SLAB vs. SLUB fixed this?

No, it does not fix the issue. However, the issue is more difficult to
re-produce. It seems easy enough to reproduce on my test server, but
seems to not happen on my test LapTop.

There are 3 related upstream commits that fix the issue (at least in my
testing) for both SLAB and SLUB, and I think (but am not sure) they have
been flagged to eventually be backported to stable. I do not think any
of the patches have made it into the current release candidate kernel
(currently 4.9-rc2) yet.

References:
https://patchwork.kernel.org/patch/9359269/
https://patchwork.kernel.org/patch/9359271/
https://patchwork.kernel.org/patch/9363679/

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1626564

Title:
  4.8 regression: SLAB is being used instead of SLUB

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

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 
threads
  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
  configs.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1626564/+subscriptions

-- 
Mailing list: https://launchpad.net/~kernel-packages
Post to     : kernel-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kernel-packages
More help   : https://help.launchpad.net/ListHelp

Reply via email to