Bug#509215: CLOSE 'top' doesn't report multi-core CPU usage properly w/ default kernel
A fresh system update (02 Jan) resolved the problem. No idea what was wrong, but things are back to normal now.
Please keep the bug closed and thanks for the help.
>From: Keith Godfrey <firstname.lastname@example.org>
>Sent: Jan 1, 2009 4:35 PM
>Cc: email@example.com, firstname.lastname@example.org
>Subject: Re: 'top' doesn't report multi-core CPU usage properly w/ default kernel
>I'd like to re-open this bug as I've again been successful at reproducing it.
>I'm not sure if it's a 'top' problem, as originally reported, or something deeper and performance related. The multi-threaded program I use as a benchmark took 17.5 hours to complete and showed an average CPU load of 85% on the default kernel (despite using 2 threads; machine 'Prevost' below). Running the same program on a very similar machine ('Pender') took 12.5 hours and showed ~190% CPU load. Prevost had similar or faster performance than Pender before the new Lenny install.
>Please advise if/how I can help, and how to re-open the bug.
>Many thanks and best regards,
>>From: Keith Godfrey <email@example.com>
>>Sent: Dec 31, 2008 11:34 AM
>>To: Moritz Muehlenhoff <firstname.lastname@example.org>
>>Subject: Re: 'top' doesn't report multi-core CPU usage properly w/ default kernel
>>I've managed to reproduce the problem, and the strange behavior is not restricted to the default kernel - I also observe odd behavior with a new kernel I've compiled, although not to the same extent. I've ran the same program on 3 different machines, all running Lenny, and the machine with a fresh Lenny install (~Dec 15th) performs notably worse than the other two.
>> Pender: Dell Optiplex 745, Core 2 duo
>> Prevost: Dell Optiplex 755, Core 2 quad, fresh install ~Dec 15th, the problem child
>> Talisman: Pentium D duo, make unknown (cluster machine)
>>As of Dec 30th: I have configured a scientific application to use 2 threads on each machine and to process the same set of data. The Core 2 duo and Pentium D duo each show ~190% CPU usage, while the Core 2 quad shows ~145%. The core 2 quad is running on a recompiled kernel. The Core 2 duo and Core 2 quad have similar clock speeds, so the application should run similarly on both. However, consistent with the CPU usage stats, the Core 2 quad runs the application at only 75% of the speed of the Core 2 duo (again, both running 2 threads).
>>As of Dec 31st: After noting these problems, I rebooted into the original kernel and reran the same application. The application running w/ 2 threads uses ~80% CPU, according to top. I'm doing a speed trial presently, but won't have results until Jan 1st (it's a big and slow simulation...)
>>Before the latest Lenny install, the Core 2 quad performed similarly (sometimes faster) than the Core 2 duo, so I don't think it's a hardware issue. It's possible that the install was bad...? The application has a huge RAM footprint and uses a lot of mutex synchronization, so, in general, application performance appears to be constrained by either bus throughput or synchronization issues. I've thought that it is possible that the new kernel reports CPU usage more accurately than previous iterations (i.e. better measuring of wait states), but the performance problems don't seem to support this hypothesis.
>>I've attached /proc/stat data from all 3 machines (specifically: cat /proc/stat > stats.machine; uname -a >> stats.machine).
>>Please let me know if there's any additional information I can provide (or additional tests).
>>>From: Moritz Muehlenhoff <email@example.com>
>>>Sent: Dec 26, 2008 4:54 PM
>>>To: Keith Godfrey <firstname.lastname@example.org>
>>>Subject: Re: 'top' doesn't report multi-core CPU usage properly w/ default kernel
>>>Keith Godfrey wrote:
>>>> I am no longer able to reproduce this bug. Please close it and I will assume that I was somehow doing something wrong (or the computer simply needed a reboot). If I am able to reproduce it again, I shall contact you.
>>>> Sorry about the apparent false alarm.
>>>Thanks, closing the bug then.
To UNSUBSCRIBE, email to debian-kernel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact email@example.com