simpler solution

Story: Howto display the number of processors in LinuxTotal Replies: 10
Author Content
Igor

Sep 02, 2007
5:50 PM EDT
type 'top' followed by 1
azerthoth

Sep 02, 2007
6:10 PM EDT
WOW, never realized top was that versatile. Type h after top starts, heck I never realized that top was interactive at all, I just used it for reference to see what the system was up to behind my back.
techiem2

Sep 02, 2007
6:23 PM EDT
For some more coolness, check out htop. http://htop.sourceforge.net/
montezuma

Sep 03, 2007
12:07 PM EDT
Hytherthreading doubles the number of physical processors....
azerthoth

Sep 03, 2007
6:26 PM EDT
techiem2 thanks for pointing out htop, I turned one of my consoles back on just so I can leave it up and running. Very handy indeed.
techiem2

Sep 03, 2007
7:12 PM EDT
Yeah, I think I've been playing with it for a couple months now. Nice and customizable with lots of features. And prettier than normal top too. :)
gus3

Sep 03, 2007
9:27 PM EDT
montezuma, HT doesn't double your CPU count. It merely doubles the number of active contexts. It's still a single core.
montezuma

Sep 04, 2007
9:11 AM EDT
gus3,

Not with you. If I type top followed by 1 on my system I get a list for cpu0, cpu1, cpu2 and cpu3 each treated equally and reporting percentage utilization. I have a dual processor Xeon chip so have only two real cpus. No where is that fact reported on top that I can see.....
azerthoth

Sep 04, 2007
11:49 AM EDT
I think although I wont swear to it, that it is in the verbiage used.

>> Hytherthreading doubles the number of physical processors....

would read better and more accurately as

Hytherthreading doubles the number of apparent processors....
montezuma

Sep 04, 2007
12:23 PM EDT
Good grief :-p all I meant to say was that if you have hyperthreading enabled (as many do) then top 1 reports the system has twice as many processors as it actually has. Therefore all these methods give inaccurate answers in a common situation
gus3

Sep 04, 2007
9:52 PM EDT
Okay, think of it this way:

In a true SMP system, say with 2 processors, each clock cycle lets your system "think" about 2 processes.There is actual decoding, additional fetching (on CISC), execution, and retirement happening two-at-a-time.

In HT, this isn't the case. Think of it as a single pipeline, but that pipeline carries a tag showing which of two different current contexts the instruction pertains to. That is, an instruction for context A (say, updatedb) can be followed immediately by another instruction for context B (Firefox?). They are both sent through the same core, but thanks to HT, neither one stomps on the other's operations: the results of updatedb's actions don't affect how Firefox executes. The net result is basically instruction-level timeslicing.

In SMP, two processes can get the full bandwidth of their CPU's, and the only clash comes in memory/cache access. In HT, the bottleneck is the pipeline itself: the bandwidth used by virtual CPU #1 is unavailable for virtual CPU #2. If you have a 2GHz CPU with HT, an evenly distributed load between two processes will run each at roughly the same speed as two 1GHz CPU's. However, if one process stalls a lot due to cache misses (and starts running like a 500MHz Pentium II), the other process will benefit from the unused pipeline bandwidth (and run like a 1.5GHz Pentium III). This benefit is mostly missing from an SMP system, where a stalled CPU does nothing to increase the pipeline bandwidth of any other CPU.

And that's my story, and I'm sticking to it.

Posting in this forum is limited to members of the group: [ForumMods, SITEADMINS, MEMBERS.]

Becoming a member of LXer is easy and free. Join Us!