Hi Doug, I believe I've now addressed this bug, see: bug 1649905
--
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
One of the 3 patches was included in the mainline kernel sometime ago.
It fixed SLAB, but not SLUB. The other two patches are now in the
mainline kernel and will appear in kernel 4.10-RC1. I'll re-test then.
--
You received this bug notification because you are a member of Kernel
Packages, which
> 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
Also: the 524 threads was with Xen PVM and two VCPUS. With one VCPU the
problem goes away. The run on 4.8.0-22-generic also had two VCPUs.
There is no problem with Xen HVM and 4.8.0-26-generic with either one or
two VCPUS.
--
You received this bug notification because you are a member of Kernel
Are you sure SLAB vs. SLUB fixed this?
I have images built from October 13 and today (October 22) with
4.8.0-22-generic and 4.8.0-26-generic respectively. On a
4.8.0-22-generic boot there are 37 kworker threads, on 4.8.0-26-generic
there are 524 kworker threads. It could be that with enough
OK, your point is valid. I was just looking at the bug title. As for why
SLAB v.s. SLUB happened, it was a regression introduced when I adopted
more modular config settings from Debian.
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to
> Doug - you should start a new bug to address your issue as this
> one will auto-close as soon as the next kernel is uploaded.
I do not understand. This one is not solved, as there two levels of
contributing factors. This one should be set back to a status of "In
Progress". Once both SLAB and
Doug - you should start a new bug to address your issue as this one will
auto-close as soon as the next kernel is uploaded.
--
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:
I filed two bug reports upstream:
https://bugzilla.kernel.org/show_bug.cgi?id=172991
https://bugzilla.kernel.org/show_bug.cgi?id=172981
I also made a kernel 4.8-rc8 with 81ae6d03 reverted (because it is so trivial
to revert) and no matter how hard I beat on it I can not get it to mess up.
**
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
> it seems the issue is not 100% solved, but is much much much less
probable.
I confirm this in bug 1626436 -- boot time is a bit faster and load now
"only" ~ 35 instead of ~ 250, but it's still a huge regression compared
to 4.4.
--
You received this bug notification because you are a member of
In case anyone is interested:
I got this far with the kernel bisection, but can only continue on Tuesday,
maybe Monday night.
** Attachment added: "bisection - thus far"
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1626564/+attachment/4748136/+files/bla1.txt
--
You received this
Note: For kernel work, I only use and compile kernels from the main
kernel.org git branch. I steal the Ubuntu kernel configuration.
The issue of a high number of kworker threads does not exist in kernel 4.6, but
does in 4.7-rc1.
When using "SLUB" it is a little difficult to detect on my Yakkety
>From my experiments, it seems the issue is not 100% solved, but is much much
>much less probable.
On my Yakkety test Laptop, if I go back to kernel 4.4.0-9136-generic I can not
create the high number of kworker threads. If I boot with kernel
4.8.0-16-generic, I can create the high number of
This bug was fixed in the package linux - 4.8.0-16.17
---
linux (4.8.0-16.17) yakkety; urgency=low
[ Tim Gardner ]
* Release Tracking Bug
- LP: #1626768
* Support ARM GIC ITS in ACPI mode (LP: #1626631)
- [Config] CONFIG_ACPI_IORT=y
- SAUCE: ACPI: I/O Remapping
..plus SLUB improves boot speed - I'm seeing ~1 second shaved off an 8.5
second boot.
--
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
I confirm that reverting the SLAB / SLUB changes in the ubuntu kernel
configuration file for mainline kernel 4.8-rc7 to the state they were in
for mainline kernel 4.7-rc4 fixes the issue (note, I disable debug,
because otherwise it takes over twice as long to compile the kernel, and
it is
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
** Changed in: linux (Ubuntu Yakkety)
Status: In Progress => Fix Committed
--
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
** Also affects: linux (Ubuntu Yakkety)
Importance: High
Status: New
** Changed in: linux (Ubuntu Yakkety)
Status: New => In Progress
** Changed in: linux (Ubuntu Yakkety)
Assignee: (unassigned) => Tim Gardner (timg-tpi)
--
You received this bug notification because you
Oh, and for the interested, the many worker thread bug in SLAB occurred
between 4.6 and 4.7. I'm not bisecting that one for now as I don't want
to use SLAB :-)
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
21 matches
Mail list logo
