SXEmacs workers work newest kernels like a bitch
Steve Youngs <steve <at> sxemacs.org>
2013-03-12 00:02:39 GMT
Hey Everyone!
I've discovered a problem with SXEmacs workers and Linux kernels since
v3.8.0-rc5-00810-g951348b. It is most likely not our fault (I hope),
but before I go bitching to the kernel folk I would like to know for
sure, and even have possible solution for them.
I think the first thing would be to find out if this is reproducible
somewhere _other_ than bastard.steveyoungs.com. So here is what you
need...
o glibc v2.15
(please try with whatever version you have, I'm stating the version
I have because libpthread is part of glibc)
o Linux kernel newer than the one mentioned above
o SXEmacs where (config-value 'EF_USE_ASYNEQ) => 1
(that isn't anything special, you'll have that by default if you
have usable pthreads)
o top(1)
(to watch the magic)
And the recipe is...
`sxemacs -no-autoloads' And then in scratch, eval
`(init-workers 8)'
You can use any number of workers you want, but 8 is quite dramatic. 
At this point have a look at top and you'll notice that the SXEmacs
process is consuming > 90% of the CPU. Compare that to a clean
-no-autoloads instance that will probably sit on about < 10% (my normal
SXE instances sit on 8% - 10% CPU).
Two odd things that I've noticed are that even though top is telling me
that my SXEmacs has eaten pretty much all of my CPU, the SXEmacs
instance itself remains every bit as responsive as it always is. And
the CPU doesn't get hot.
Those two things make me believe that something is making top lie to
me. I have tried other monitoring thingies like KDE's "System Monitor"
and they agree with top.
I bisected the kernel repo and found that
b5c78e04dd061b776978dad61dd85357081147b0 is the revision where this
began. However, it doesn't make any sense to me at all. See for
yourself...
commit b5c78e04dd061b776978dad61dd85357081147b0
Merge: 06991c2 951348b
Author: Linus Torvalds <torvalds <at> linux-foundation.org>
Date: Thu Feb 21 12:11:44 2013 -0800
Merge tag 'staging-3.9-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging
Pull staging tree update from Greg Kroah-Hartman:
\"Here's the big staging tree merge for 3.9-rc1
Lots of cleanups and updates for drivers all through the staging tree.
We are pretty much \"code neutral\" here, adding just about as many
lines as we removed.
All of these have been in linux-next for a while.\"
* tag 'staging-3.9-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging: (804 commits)
staging: comedi: vmk80xx: wait for URBs to complete
staging: comedi: drivers: addi-data: hwdrv_apci3200.c: Add a missing semicolon
staging: et131x: Update TODO list
staging: et131x: Remove assignment of skb->dev
staging: wlan-ng: hfa384x.h: fix for error reported by smatch
staging/zache checkpatch ERROR: spaces prohibited around that
staging/ozwpan: Mark read only parameters and structs as const
staging/ozwpan: Remove empty and unused function oz_cdev_heartbeat
staging/ozwpan: Mark local functions as static (fix sparse warnings)
staging/ozwpan: Add missing header includes
staging/usbip: Mark local functions as static (fix sparse warnings)
staging/xgifb: Remove duplicated code in loops.
staging/xgifb: Consolidate return paths
staging/xgifb: Remove code without effect
staging/xgifb: Remove unnecessary casts
staging/xgifb: Consolidate if/else if with identical code branches
staging: vt6656: replaced custom TRUE definition with true
staging: vt6656: replaced custom FALSE definition with false
staging: vt6656: replace custom BOOL definition with bool
staging/rtl8187se: Mark functions as static to silence sparse
...
diff --cc drivers/power/generic-adc-battery.c
index 836816b,42733c4..8cb5d7f
--- a/drivers/power/generic-adc-battery.c
+++ b/drivers/power/generic-adc-battery.c
<at> <at> <at> -284,11 -287,10 +284,11 <at> <at> <at> static int gab_probe(struct platform_de
* based on the channel supported by consumer device.
*/
for (chan = 0; chan < ARRAY_SIZE(gab_chan_name); chan++) {
- adc_bat->channel[chan] = iio_channel_get(dev_name(&pdev->dev),
- gab_chan_name[chan]);
+ adc_bat->channel[chan] = iio_channel_get(&pdev->dev,
+ gab_chan_name[chan]);
if (IS_ERR(adc_bat->channel[chan])) {
ret = PTR_ERR(adc_bat->channel[chan]);
+ adc_bat->channel[chan] = NULL;
} else {
/* copying properties for supported channels only */
memcpy(properties + sizeof(*(psy->properties)) * index,
I can't see how the diff and the log could possibly be related to one
another, and I can't see how the diff could possibly affect pthread
related things. In fact, this makes so little sense to me that I am
inclined to bisect the kernel repo again just be doubly certain.
If you can help, even by just confirming (or not) that the recipe is
reproducible, please do. Thanks!
--
--
|---<Steve Youngs>---------------<GnuPG KeyID: A94B3003>---|
| SXEmacs - The only _______ you'll ever need. |
| Fill in the blank, yes, it's THAT good! |
|------------------------------------<steve <at> sxemacs.org>---|
lisp and C traces attached
RSS Feed