simpler solution
|
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!