I was working on the assumption that the same commit was causing both the SLAB and the remaining SLUB issues, however it turns out that assumption was incorrect.
The commit that causes the SLAB issue is: 801faf0db8947e01877920e848a4d338dd7a99e7 "mm/slab: lockless decision to grow cache" The commit that causes the remaining SLUB issue is: 81ae6d03952c1bfb96e1a716809bd65e7cd14360 "mm/slub.c: replace kick_all_cpus_sync() with synchronize_sched() in kmem_cache_shrink()" It turns out that they just so happen to be adjacent commits in the tree. I will attempt to make e-mails for upstream, but it'll take me awhile. (Anyone willing to review before I send them?) -- 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
