- Site menu:
- Latest Discussions
- Latest Newswire
- Archives
- Submit Story
- Story HOWTO
- Syndicate
- E-mail Alerts
Howto display the number of processors in Linux
If you’ve just bought a new desktop,laptop or server and the box says the box is powered by 2 processors, you can actually verify that. |
|
|
Comments (11)
type 'top' followed by 1
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.
For some more coolness, check out htop.
http://htop.sourceforge.net/
Hytherthreading doubles the number of physical processors....
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.
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. :)
montezuma, HT doesn't double your CPU count. It merely doubles the number of active contexts. It's still a single core.
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.....
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.....
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....
>> Hytherthreading doubles the number of physical processors....
would read better and more accurately as
Hytherthreading doubles the number of apparent processors....
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
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.
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.
Post a comment
A free account is needed to post. Write your comment here first: your text is kept in this browser while you sign up or log in, and is waiting for you when you come back.
Your message:Markdown: **bold**, *italic*, [text](https://link), - lists, > quotes, $x^2$ for math. Formatting help
Sign up and post (it is free) or Log in and post