Multi-core load balancing not working properly after suspend to disk
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
linux (Ubuntu) |
Expired
|
Undecided
|
Unassigned |
Bug Description
CPU: Intel(R) Core(TM) i7 CPU 860, 4 cores, hyperthreading
Symptoms: After suspending to disk load balancing of processes across CPU cores is not working properly. Runnable processes have to share a CPU core even if idle CPU cores are available. This is particularly noticeable when running parallel builds (e.g. make -j8 ...). They take much longer and the GNOME system monitor applet shows that most CPU cores are idle when there is enough work to keep them all busy.
A simple test to visualize the problem is to run "(while true; do true; done) & (while true; do true; done)" in bash and look at the CPU usage in top. After a fresh boot, the two subshells run with 100% CPU usage each, so each gets its own core to run on. When running this experiment after a suspend/resume cycle the two subshells run with 50% CPU usage each, so they're made to share a CPU core, although idle CPU cores are available.
Steps to reproduce:
* Boot system
* log in as normal user
* run the following command in a terminal window running bash: (while true; do true; done) & (while true; do true; done)
* In a second terminal window run top and observe two bash processes at the top, each running with 100% CPU usage
(each bash gets its own CPU core)
* kill the two bash subshell processes
* suspend to disk
* wake up the system
* Run the same command as above: (while true; do true; done) & (while true; do true; done)
* In top the two bash processes run with 50% CPU usage
(the two bash processes apparently share one CPU core, although idle cores are available)
Expected result: load balancing should continue working after resuming. The two bash subshells should each run with 100% CPU usage.
Actual result: load balancing is broken after resume. The two bash subshells have to share a CPU core even when idle CPU cores are available to balance the load.
ProblemType: Bug
DistroRelease: Ubuntu 10.10
Package: linux-image-
Regression: Yes
Reproducible: Yes
ProcVersionSign
Uname: Linux 2.6.35-22-generic x86_64
NonfreeKernelMo
AlsaVersion: Advanced Linux Sound Architecture Driver Version 1.0.23.
Architecture: amd64
ArecordDevices:
**** List of CAPTURE Hardware Devices ****
card 0: Intel [HDA Intel], device 0: VT1828S Analog [VT1828S Analog]
Subdevices: 2/2
Subdevice #0: subdevice #0
Subdevice #1: subdevice #1
AudioDevicesInUse:
USER PID ACCESS COMMAND
/dev/snd/
/dev/snd/pcmC0D0p: fkuehlin 1753 F...m pulseaudio
CRDA: Error: [Errno 2] No such file or directory
Card0.Amixer.info:
Card hw:0 'Intel'/'HDA Intel at 0xfbaf8000 irq 52'
Mixer name : 'VIA VT1828S'
Components : 'HDA:11064441,
Controls : 35
Simple ctrls : 20
Card1.Amixer.info:
Card hw:1 'Generic'/'HD-Audio Generic at 0xfbbfc000 irq 53'
Mixer name : 'ATI R6xx HDMI'
Components : 'HDA:1002aa01,
Controls : 4
Simple ctrls : 1
Card1.Amixer.
Simple mixer control 'IEC958',0
Capabilities: pswitch pswitch-joined penum
Playback channels: Mono
Mono: Playback [on]
Date: Fri Oct 15 14:56:46 2010
HibernationDevice: RESUME=
InstallationMedia: Ubuntu 10.04 LTS "Lucid Lynx" - Release amd64 (20100429)
IwConfig:
lo no wireless extensions.
eth0 no wireless extensions.
MachineType: System manufacturer System Product Name
ProcCmdLine: BOOT_IMAGE=
ProcEnviron:
PATH=(custom, user)
LANG=en_CA.UTF-8
SHELL=/bin/bash
RelatedPackageV
RfKill:
SourcePackage: linux
WifiSyslog:
Oct 15 14:55:59 Harpoon kernel: [17206.856773] ACPI Warning: Incorrect checksum in table [OEMB] - 0x03, should be 0xED (20100428/
Oct 15 14:55:59 Harpoon kernel: [17206.856958] ACPI Warning: Incorrect checksum in table [OEMB] - 0x03, should be 0xED (20100428/
dmi.bios.date: 03/25/2010
dmi.bios.vendor: American Megatrends Inc.
dmi.bios.version: 1408
dmi.board.
dmi.board.name: P7P55D
dmi.board.vendor: ASUSTeK Computer INC.
dmi.board.version: Rev 1.xx
dmi.chassis.
dmi.chassis.type: 3
dmi.chassis.vendor: Chassis Manufacture
dmi.chassis.
dmi.modalias: dmi:bvnAmerican
dmi.product.name: System Product Name
dmi.product.
dmi.sys.vendor: System manufacturer
tags: | added: acpi-table-checksum |
Changed in linux (Ubuntu): | |
status: | New → Confirmed |
Felix Kuehling, this bug was reported a while ago and there hasn't been any activity in it recently. We were wondering if this is still an issue? If so, could you please test for this with the latest development release of Ubuntu? ISO images are available from http:// cdimage. ubuntu. com/daily- live/current/ .
If it remains an issue, could you please run the following command in the development release from a Terminal (Applications- >Accessories- >Terminal) , as it will automatically gather and attach updated debug information to this report:
apport-collect -p linux <replace- with-bug- number>
Also, could you please test the latest upstream kernel available following https:/ /wiki.ubuntu. com/KernelMainl ineBuilds ? It will allow additional upstream developers to examine the issue. Please do not test the daily folder, but the one all the way at the bottom. Once you've tested the upstream kernel, please comment on which kernel version specifically you tested. If this bug is fixed in the mainline kernel, please add the following tags: fixed-upstream fixed-upstream- VERSION- NUMBER
kernel-
kernel-
where VERSION-NUMBER is the version number of the kernel you tested. For example: fixed-upstream- v3.11-rc5
kernel-
This can be done by clicking on the yellow circle with a black pencil icon next to the word Tags located at the bottom of the bug description. As well, please remove the tag: testing
needs-upstream-
If the mainline kernel does not fix this bug, please add the following tags: bug-exists- upstream bug-exists- upstream- VERSION- NUMBER
kernel-
kernel-
As well, please remove the tag: testing
needs-upstream-
If you are unable to test the mainline kernel, please comment as to why specifically you were unable to test it and add the following tags: unable- to-test- upstream unable- to-test- upstream- VERSION- NUMBER
kernel-
kernel-
Once testing of the upstream kernel is complete, please mark this bug's Status as Confirmed. Please let us know your results. Thank you for your understanding.