Bug 51691 - High cpu overhead on using multiple cores
Summary: High cpu overhead on using multiple cores
Alias: None
Product: Process Management
Classification: Unclassified
Component: Scheduler (show other bugs)
Hardware: All Linux
: P1 normal
Assignee: Ingo Molnar
URL: https://bugs.launchpad.net/ubuntu/+so...
Depends on:
Reported: 2012-12-13 11:04 UTC by sworddragon2
Modified: 2016-03-23 18:25 UTC (History)
4 users (show)

See Also:
Kernel Version: 3.7
Regression: No
Bisected commit-id:

Example script (251 bytes, text/x-python)
2012-12-13 11:04 UTC, sworddragon2
Log of top using 1 and 2 cores (19.74 KB, text/x-log)
2012-12-13 11:04 UTC, sworddragon2
Example in C (320 bytes, text/x-csrc)
2013-01-03 03:18 UTC, sworddragon2
Example in C (367 bytes, text/x-csrc)
2013-04-19 20:33 UTC, sworddragon2
Testcase (447 bytes, text/x-csrc)
2013-11-20 12:20 UTC, sworddragon2

Description sworddragon2 2012-12-13 11:04:35 UTC
Created attachment 89101 [details]
Example script

On my AMD Phenom II X6 1045T if a process uses multiple cores it has a very high cpu overhead (an average of 50%) compared to limiting the process to 1 cpu core. In the attachments is:

- The script which was used for the test. It creates 2 threads which are in semi-idle (using ~10-20% of one core per thread on my system).
- A log which shows top with a process (the script) which needed more cpu power before it was limited with taskset to 1 core.
Comment 1 sworddragon2 2012-12-13 11:04:53 UTC
Created attachment 89111 [details]
Log of top using 1 and 2 cores
Comment 2 Alan 2013-01-02 14:18:40 UTC
You need to profile your application and interpreter at a low level - most likely you've got contention problems. Doesn't seem to be a kernel bug here
Comment 3 sworddragon2 2013-01-03 03:18:02 UTC
I have now port the script to C to exclude Python as the source of the problem. The bug appears there too. My cpu usage on 1 core with 2 threads is ~14% and on 2 cores with 2 threads ~21%.
Comment 4 sworddragon2 2013-01-03 03:18:37 UTC
Created attachment 90241 [details]
Example in C
Comment 5 Tomáš Pružina 2013-04-19 17:18:30 UTC
Please close the bug, not a kernel problem.
Infinite loop of usleeps(0.0000001) will in fact cause 'slight overhead'.

usleep defined ranges [0,1000 000], not sure how did that float went unnoticed by compiler.
Comment 6 Tomáš Pružina 2013-04-19 20:22:12 UTC
nevermind my last comment.
Comment 7 sworddragon2 2013-04-19 20:32:22 UTC
Don't worry - you have helped me to find a potential error in my testcase. I have updated it to use nanosleep() instead but the result is still the same - multiple cores will produce much overhead.
Comment 8 sworddragon2 2013-04-19 20:33:14 UTC
Created attachment 99371 [details]
Example in C
Comment 9 sworddragon2 2013-11-20 12:19:06 UTC
Here is an updated version of the testcase. It uses now number of online core * 2 as threads because the overhead gets much higher with more threads. Here are the results on my system with 12 threads:

Calling ./test will result in a cpu usage of ~185%/600%.
Calling taskset -c 0 ./threads will result in a cpu usage of ~30%/600%.
Comment 10 sworddragon2 2013-11-20 12:20:29 UTC
Created attachment 115241 [details]

Compiling with "gcc -o threads ./threads.c -lpthread".

Note You need to log in before you can comment on or make changes to this bug.