Bug 112597 - SMP kernel does not utilize second processor
Summary: SMP kernel does not utilize second processor
Alias: None
Product: Fedora
Classification: Fedora
Component: kernel   
(Show other bugs)
Version: 1
Hardware: i686
OS: Linux
Target Milestone: ---
Assignee: Arjan van de Ven
QA Contact:
Depends On:
TreeView+ depends on / blocked
Reported: 2003-12-24 04:13 UTC by Craig Lawson
Modified: 2007-11-30 22:10 UTC (History)
4 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2004-09-29 19:52:22 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

Description Craig Lawson 2003-12-24 04:13:10 UTC
Description of problem:
The SMP kernel recognizes but does not utilize the second processor.

Version-Release number of selected component (if applicable):
kernel-smp-2.4.22-1.2115.nptl.i686.rpm, and 
kernel-smp-2.4.22-1.2121.2.1.nptl.i686.rpm, and

How reproducible:

Steps to Reproduce:
1. Install Fedora Core SMP kernel on a P-4/Hyperthreading system.
2. Reboot.
Actual results:
The kernel boots and for all appearances seems to understand that it
is running on a dual processor system. Details:

1. dmesg indicates that two identical processors are detected and
initialized during boot.

2. /proc/cpuinfo shows two processors active.

3. gkrellm and top both display CPU utilization for two processors.

But no matter how I load the system, both top and gkrellm indicate
non-zero utilization for CPU0 only. Utilization for CPU1 is always
exactly 0%.

Expected results:
I expect gkrellm and top to show non-zero utilization for CPU1 sometimes.

Additional info:
My system is a P-4 with Hyperthreading and 1 Gb RAM. When I run with a
standard release RedHat SMP kernel (examples: 2.4.20-20.9smp and
2.4.20-24.9smp), all of the behavior I listed under "Expected results"
actually happens.

Comment 1 Andy Rysin 2004-01-14 20:24:05 UTC
I can confirm this on my machine too with kernels
vmlinux-2.4.22-1.2140.nptlsmp and vmlinux-2.4.22-1.2149.nptlsmp
While kernel vmlinux-2.4.22-20.1.2024.2.36.nptlsmp shows the load on
both logical CPUs ok.
P4 2.60GHz

top and sar always show the same 100% idle for second CPU

It seems like the change happend between 2.4.22-20.1.2024 and

Comment 2 Andy Rysin 2004-02-13 08:19:32 UTC
Also checked the same P4 with HT on vanilla kernel 2.4.24 and it works
fine. Fedora kernel updates up to 2.4.22-1.2166 still don't use second
Also I tried Fedora kernels on Dual-Xeon system and all 4 logical CPU
were used fine.

Comment 3 Brent H. 2004-03-20 07:01:16 UTC
Looks similar to

Comment 4 Pete Zaitcev 2004-04-22 03:27:24 UTC
A gentleman in our LUG complained about the same issue and I asked
him to test ACTUAL speed by running two, three and four identical
programs simultaneously, while timing them with a stopwatch.
His results indicated a proper execution time, although it was
all in oral communication. At this moment, I suspect a deficiency
in either pstools or kstat, rather than the kernel.

He was going to take the box at the next installfest for me to look.
Meanwhile, can someone measure how fast CPU intensive programs run?
The gnuchess seems like a good test.

Comment 5 Greg Sharp 2004-06-07 22:43:05 UTC
I have three nearly identical dell dimension 3600 systems.  This
problem occurs on one of the three units.  I would be glad to send any
comparison information about these units if this would help.

I have confirmed this problem occurs with kernels:


Browsing the web yields little information about this problem. There
is one vague report that this is fixed in the 2.6 kernel here:


@Pete, I have confirmed informally using the wall clock that only one
CPU is running my jobs.  Running two computationally intensive tasks
concurrently takes double the time as running them sequentially.

Comment 6 Greg Sharp 2004-06-08 21:44:11 UTC
1)  Running like this:

run -b 1 ./a.out

does indeed show (using top) that the job runs on the idle processor.

2)  However, there is no performance gain compared to serialized 
execution. Using a test program (a spin-lock) on a freshly booted 
machine, I benchmarked serialized vs concurrent execution using wall 
clock like this:

date; ( run -b 0 ./a.out & run -b 1 ./a.out & wait ) ; date         #
date; ( ./a.out ; ./a.out ; wait ) ; date                           #

Both commands require the same time to execute, verified with 3 runs 

3)  Then, I checked my "good" machines.  Similar test as in #2 
(without the "run -b" stuff), and same result as in #2.  Absolutely 
no performance gain from SMP.  These machines are 3.0GHz P4/HT.

Comment 7 David Lawrence 2004-09-29 19:52:22 UTC
Thanks for the bug report. However, Red Hat no longer maintains this version of
the product. Please upgrade to the latest version and open a new bug if the problem

The Fedora Legacy project (http://fedoralegacy.org/) maintains some older releases, 
and if you believe this bug is interesting to them, please report the problem in
the bug tracker at: http://bugzilla.fedora.us/

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