CONCURRENCY_LEVEL variable and quad core chips

Here you can discuss every aspect of Debian. Note: not for support requests!

CONCURRENCY_LEVEL variable and quad core chips

Postby graysky » 2008-12-16 21:57

I have read conflicting info about what number to use when setting the CONCURRENCY_LEVEL variable prior to compiling a kernel. Some guides teach to use 1+ the number of cores (5 in the case of a quad and 3 in the case of a dual) while others teach to use the number of cores (4 in the case of a quad and 2 in the case of a dual).

You can search these forums for guides on compiling it. Here is my favorite one.

I did a few compiles of the Lenny 2.26.6-1-amd64 kernel (just copied the /boot/config-2.6.26-1-amd64 to /usr/src/linux-source-2.6.26/.config) using a value for X in the code below of 1, 3, 4, and 5:

Code: Select all
# export CONCURRENCY_LEVEL=X
# fakeroot make-kpkg clean
# time fakeroot make-kpkg --append-to-version "-trash" --revision "1" --us --uc --initrd kernel_image kernel_headers


Here are the results:

CONCURRENCY_LEVEL=1
real 27m55.944s
user 23m56.166s
sys 3m42.652s

CONCURRENCY_LEVEL=3
real 11m20.945s
user 23m33.358s
sys 3m45.215s

CONCURRENCY_LEVEL=4
real 10m51.692s
user 22m57.254s
sys 3m42.559s

CONCURRENCY_LEVEL=5
real 12m28.570s
user 23m10.479s
sys 3m49.568s

Image

Hardware specs: Xeon X3360 @ 8.5x400 = 3.40 GHz; 4 gigs of DDR2 @ 1,003 MHz, Debian/Lenny-amd64.

Just so you know, they don't scale in a linear fashion because of many factors including, I/O limitations, the fact that the whole process isn't CPU limited, not all cores get 100 % utilization, etc. Another factor I wanted to share is that the entire compile isn't using all four cores. For example, when making the debs, only one core is used. When writing the modules, the HDD becomes the limiting factor, etc.

Just wanted to share these with the group. Based on this small data set, one should NOT use 1+number of cores with CONCURRENCY_LEVEL. I also did a similar analysis using make -jx.
Last edited by graysky on 2008-12-20 10:34, edited 3 times in total.
User avatar
graysky
 
Posts: 495
Joined: 2008-10-10 20:58

Postby plugwash » 2008-12-17 16:55

Afaict the advantage of using +1 is that it means work can be done by all cores even while one process is waiting for disk IO etc. The downside is that there will be far more context switches.

So I would imagine the advantage or disadvantage of using +1 to depend on the speed of your storage subsystem.
plugwash
 
Posts: 2508
Joined: 2006-09-17 01:10

Postby graysky » 2008-12-17 18:51

That's a good point... my system has pretty standard 7200 RPM HDDs (SATA-2) not configured in a RAID. Maybe someone with a quad chip and a RAID array can give it a try to test your hypothesis.
User avatar
graysky
 
Posts: 495
Joined: 2008-10-10 20:58

Postby AdrianTM » 2009-01-02 17:28

I use 2 for dual core, I found out that if I use 3 it's slower.

One more thing to take into consideration, every time you run the compilation the second time it will be faster because of buffers, so kernel compilation it's not quite a good benchmark.
Ubuntu hate is a mental derangement.
User avatar
AdrianTM
 
Posts: 2520
Joined: 2004-09-19 01:08

Postby graysky » 2009-01-02 18:00

AdrianTM wrote:I use 2 for dual core, I found out that if I use 3 it's slower.

One more thing to take into consideration, every time you run the compilation the second time it will be faster because of buffers, so kernel compilation it's not quite a good benchmark.


...is this true even after the make clean step?
User avatar
graysky
 
Posts: 495
Joined: 2008-10-10 20:58

Postby AdrianTM » 2009-01-02 18:12

In my experience, yes. Try for yourself, compile once, make clean, compile the second time with the same parameters.

The whole process depends on what else you do on that computer, if you want to compare things you have to have the same amount of free memory for example.
Ubuntu hate is a mental derangement.
User avatar
AdrianTM
 
Posts: 2520
Joined: 2004-09-19 01:08


Return to General Discussion

Who is online

Users browsing this forum: No registered users and 8 guests

fashionable