 | | | Dual-core & Parallel Compile Issues | Dual-core & Parallel Compile Issues 2005-12-06 - By Stephen J. Smoogen
Back
On 12/6/05, Brian Long <brilong@(protected)> wrote:
> Hello folks,
>
> I'm grasping at straws here hoping someone else has run into issues
> running dual-core Opterons (Sun V40z specifically). When we run a large
> parallel compile with various j values (i.e. -j8, -j16, -j24, -j32,
> -j40), we are able to compile the end product in much less time on a
> quad single-core V40z (quad Opteron 852 / 2.6GHz) than on a quad
> dual-core V40z (quad Opteron 875 / 2.2GHz). For example, with -j20, 7.4
> mins vs. 9.6 mins without ClearCase and 13.7 mins. vs. 18.6 mins with
> ClearCase). We have tried on the U5 and U6 kernel with zero improvement
> seen between the two.
>
> When compiling with large -j values on the dual-core system, the CPUs
> stay 80% idle the majority of the time (as measured by sar on 10-sec
> interval). On the single-core system, the CPU is much more utilized
> throughout the build. I can provide graphs if anyone is interested. We
> have not yet tried to duplicate the issue on RHEL 4 U2, but plan to try
> in the next few days.
>
> I would appreciate any pointers on how we might further investigate what
> is causing the bottleneck. Are there known issues with the RHEL 3
> kernel scheduler or anything else I should be aware of? Thanks.
>
Well I would check to see where the scaling problem occurs to see if
it is a problem with dual core or going above 4 processors (or both)?
The tests I would try would be the following:
1 Single Core CPU vs 1 Double Core CPU (UP versus SMP test)
2 Single Core CPU vs 1 Double Core CPU (SMP versus SMP test)
4 Single Core CPU vs 2 Double Core CPU (Bigger scale issue)
4 Single Core CPU vs 4 Double Core CPU (greater than 4 cpus test)
Graphing that out might be able to pin it down where it begins to fall
over. There is a limit of how well a 2.4 kernel is going to deal with
64 bit dual-core loveliness.. there is also the usual limits that
motherboards secretly have with not being ideally set up for bus
interactions for disks and such (that might cause a spin lock to go
longer than expected).
This is from a guy though who only has an 800mhz Pentium III quad core
so take with usual grain of salt.
--
Stephen J Smoogen.
CSIRT/Linux System Administrator
--
Taroon-list mailing list
Taroon-list@(protected)
https://www.redhat.com/mailman/listinfo/taroon-list
|
|
|