[06:52] <dsmythies> Additionally: If I look at linux/Documentation/workqueue.txt and do "echo workqueue:workqueue_queue_work > /sys/kernel/debug/tracing/set_event" and "cat /sys/kernel/debug/tracing/trace_pipe > out.txt"
[06:53] <dsmythies> with the issue, I get somwhere between 10,000 and 20,000 occurances of memcg_kmem_cache_create_func in the file.
[06:54] <dsmythies> without the issue, I get 21, and an overall file size about 50 times smaller, for otherwise similar conditions.
[06:55] <dsmythies> Using a simplified method to create the issue that I made.
[09:54] <caribou> Hello, just an FYI : makedumpfile is failing on 4.8 kernels (i.e. Yakkety). I'm on the issue and should fix it today
[09:56] <apw> caribou, thanks, if you have a bug for that could you tag it kernel-4.8 so we see it too
[09:56] <caribou> apw: sure : LP: #1626269
[09:56] <ubot5`> Error: Could not gather data from Launchpad for bug #1626269 (https://launchpad.net/bugs/1626269). The error has been logged
[09:56] <apw> ubot you are just a waste of electrons
[10:09] <smb> apw, caribou I added the tag
[10:09] <caribou> smb: thanks!
[12:19]  * xnox hates EFI
[12:19] <xnox> so much respins, so much to test =)
[12:41] <davmor2> xnox: they'll be more yet
[12:43] <rtg> dsmythies, any luck on changing CONFIG_NR_CPUS to something less then 8192 ?
[13:08] <apw> rtg, that was not succesful, cking is debugging
[13:49] <rtg> dsmythies, I've been informed that http://bugs.launchpad.net/bugs/1626564 is likely the root of your kworker issue
[13:49] <ubot5`> Ubuntu bug 1626564 in linux (Ubuntu Yakkety) "4.8 regression: SLAB is being used instead of SLUB" [High,In progress]
[14:16] <dsmythies> rtg: Indeed, SLUB is a difference between 4.7-rc4 and 4.7-rc5, and not something that I had tried reverting. I have an inredibly simple way to demonstrate this issue. I'll add to the bug report.
[14:17] <rtg> dsmythies, I credit apw and cking for finding root cause
[14:18] <apw> cking, did all the heavy lifting ...
[14:23] <mterry> I'm experiencing system "slowdown" in yakkety -- that's a known issue?
[14:24] <apw> mterry, particularly in early boot yes
[14:24] <mterry> Ah.  Maybe different then.  I'm experiencing system unresponsiveness if anything is happening (like compiling, browsers using cpu)
[14:25] <mterry> Desktop experience gets quite bad, can't barely type
[14:25] <apw> rtg, perhaps we should have a dirty build with the curent fixes so we can see if things like this is the same or a new issue
[14:30] <JanC> mterry also mentioned seeing “crazy high occasional loads”
[14:31] <mterry> Yeah.  Browsers and such tend to go mental in top, which helps trigger the unresponsiveness.  But I don't know if they are going mental because of initial unresponsiveness problem that spirals out of control?
[14:32] <mterry> Yeah.  Browsers and such tend to go mental in top, which helps trigger the unresponsiveness.  But I don't know if they are going mental because of initial unresponsiveness problem that spirals out of control?
[15:11] <dannf> rtg: do you want SRU bugs opened for pull requests for yakkety at this point - if not, when does that change?
[15:13] <bjf> dannf, yes .. bugs, please
[15:13] <dannf> bjf: ack
[15:15] <rtg> dannf, please do
[15:35] <dsmythies> Confirmed: reverting SLAB /SLUB kernel configuration changes solves the over 2000 kworker threads issue. As a side effect, and as expected, it also solves rediculous load average values after boot. i.e. "load average: 430.90, 99.40, 32.78"
[15:38] <chalbersma> Is this Ask Ubuntu Accurate (http://askubuntu.com/questions/804111/is-no-reboot-kernel-patching-enabled-in-16-04)? Is there now live kernel patching in Ubuntu 16.04? I asked on #ubuntu and they said they didn't think so but I should check with you guys.
[15:45] <apw> chalbersma, the statements in there are accurate in that the facility to _do_ live kernel patching is included, there is no stream of such patches though
[15:47] <chalbersma> Has there been any live patches released?
[15:50] <apw> not to my knowledge no
[15:51]  * ogra_ notes that hot-patching does not necessarily mean no reboots ... if you patch changes something that lives in the initrd you most likely want to re-generate it and actually also ask for rebooting
[15:51] <ogra_> (and there are surely other cases where a hot patch will still cause reboots)
[15:59] <chalbersma> Thanks guys just wanted to clear that up. 
[16:04] <apw> .b 6
[16:30] <_ami_> which driver is responsible for serial over ip in linux?
[16:35] <apw> that is normally called sol in the kernel side if it is coming via a bmc, though in my experience sol is handled by the device and faked to the machine as a real serial port
[17:01] <_ami_> apw: ok, thanks
[18:10] <om26er> Hello! It seems the 4.8 Update on Yakkety have brought in some troubles. 1. My system becomes sluggish during load. 2. There is a lag in screen brightness keystrokes actually taking effect.
[18:34] <apw> om26er, yes indeed, the first one we know the fix, the second we are investigating
[19:31] <tdaitx> apw, hi there! we have some sort of mismatching headers between powerpc/ppc64el and the other archs that is causing a few packages to FTBFS on powerpc/ppc64el, I stumbled upon freevo's FTBFS and slangasek said he saw other packages failing due to a similar reason... he said you might be able to help me on that, the current bug is LP: #1619446
[19:31] <ubot5`> Launchpad bug 1619446 in linux (Ubuntu) "mismatching headers between powerpc/ppc64el and other archs" [Medium,Triaged] https://launchpad.net/bugs/1619446
[19:32] <tdaitx> please let me know when it is a good time to talk about that
[19:44] <apw> tdaitx, there should be a new linux-libc-dev hitting the archive about now ... could you confirm it is the same there and add that to the bug
[19:44] <tdaitx> apw, sure, I will check that, thanks for the info
[20:43] <rtg> dannf, I've pulled your changes. Please build yourself a test kernel to check if I've broken any arm64 config settings. I've been syncing with Xenial after modularizing everything.
[20:52] <dannf> rtg: sure and thx
[22:24] <tdaitx> apw, did you refer to version linux-libc-dev 4.8.0-15.16? it still FTBFS with that one