Hide Forgot
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 kernel-smp-2.4.22-1.2135.nptl.i686.rpm How reproducible: 100% 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.
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 512MB RAM 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 2.4.22-1.2115
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 CPU. Also I tried Fedora kernels on Dual-Xeon system and all 4 logical CPU were used fine.
Looks similar to https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=118330
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.
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: 2.4.22-1.2115 2.4.22-1.2188 Browsing the web yields little information about this problem. There is one vague report that this is fixed in the 2.6 kernel here: http://www.mandrakeusers.org/index.php?s=079cde6c7ca3360fe44da12888ee8d08&showtopic=14176&st=0&#entry115384 @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.
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 # concurrent date; ( ./a.out ; ./a.out ; wait ) ; date # serialized Both commands require the same time to execute, verified with 3 runs each. 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.
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 persists. 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/