procps/README.top

252 lines
13 KiB
Plaintext
Raw Normal View History

2002-10-14 03:27:07 +05:30
Ok, ok, I yield -- much of what follows has been removed from the manual page
and packaged separately as this README. Which means, of course, that absolutely
nobody will ever read it.
If that proves to be wrong, I hope the individual will drop a line to:
procps-feedback@lists.sourceforge.net
Just say "Ha, I read it!" and the author will die happy (but not right away).
Thanks.
## Table of Contents ---------------------------------------------------##
NOTES and Rantings
CUSTOMIZING the Sources
## 7. NOTES and Rantings -----------------------------------------------##
7a. The top Binary
To whom it may (should) concern: this top, even with its vastly
expanded capabilities, is only slightly larger than the old top.
Were it not for extensive help text and additional sort callbacks,
it would be smaller.
Throw source carelessly at objectives, it will
produce equally careless machine instructions.
example: (num_pages - an_address)/1024 == duh?
kicker: document result as broken, due to elf!
----------------------------------------------
I know you're out there, are you getting this?
Now, as for all those new capabilities like colors and windows and
highlighting, you'd expect this top to be the "mother of all pigs"
compared to old top -- right?
Yea, with this top expect following piglets:
. A smaller virtual image and resident footprint
. Slightly fewer major page faults
. A large reduction in minor page faults for SMP
. The same or better response time
. The same or even less CPU costs
Ideally any comparison of the old and new top should be against
the same libproc format (32-bit or 64-bit tics) and run in a true
or simulated SMP environment (producing separate CPU stats). This
latter requirement will coax old top into handling his own
'/proc/stat' access -- something this top always does, but with
less cost.
7b. Comparing Performance
Even with equivalent libraries and '/proc/stat' access, it's dif-
ficult to accurately compare tops using their own displays.
Results for these cpu-intensive programs (who frequently exceed
their time-slice) generally show a wide disparity in %CPU. This
is due to differing call patterns, kernel preemptions and the tim-
ing of process snapshots. For slightly better results, start each
program with the following commands:
./old-top -d 0.5
nice -n-10 ./new-top -d 0.4
While actually putting this top at a performance disadvantage, the
higher scheduling priority and staggered timing will periodically
yield a somewhat truer picture. You could even reverse those
roles and get similar results.
The most consistent performance results will be obtained 'off-
line', using your shell's time pipe or the time program itself.
And even in a single processor environment or without equivalent
libraries, total cpu costs (user time + system time) are similar.
However, this top's cpu costs ARE influenced by the capabilities
you choose to exploit, even if they don't SEEM to be reflected in
such timings. So let's examine some...
7c. Cost of Stuff
Colors Cost -- Nada (almost).
Once the terminfo strings are built (at and during a user's
behest) they are SAVED with each window's stuff. And while
there will be extra tty escape sequences transmitted because of
colors, it makes no difference which 'char *' is actually used.
Highlighting Cost -- Nada (maybe), or blame it on Rio.
On second thought, let's blame it on the user.
For row highlighting, there is only the cost of those extra tty
escape sequences (same as for colors). For column highlight-
ing, there is a fairly significant cost associated with column
transition management combined with even more tty output.
These increased costs are incurred on every task display row.
Sooo... hey USER -- do NOT highlight COLUMNS. You shouldn't
need a constant visual reminder of your chosen sort field.
However, if you forget which field top is sorting it can serve
as a quick visual reminder.
Windows Cost -- Nada (if just 1 window).
If more than 1 window, almost certainly NOT Nada so blame it on
reality. Colors are not an issue, but those sort fields are.
If we could trust the user to always select the same 'c' state,
'S' state and sort field (hey, why ya got multiple windows then
user, huh?) AND if we can trust someone to recompile top with a
#define enabled, then we could achieve 'Nada'.
Ok, not likely, so we're gonna' be doing multiple sorts. BUT,
it may not be as bad as it sounds. Those sorts involve point-
ers only. And, that's as good as it gets ! (right Mr. N?)
7d. The top Sources
top.h
Unlike his predecessor, this top has a proper header file. It
contains ONLY declarations, NOT definitions. And there are
several conditionals present to help with further customiza-
tions and experimentation. All are Off by default.
top.c
Hopefully proves that source code needn't be a disorganized,
misaligned MESS. And, WHO says a source listing shouldn't
occasionally make you SMILE? Why, top.c even does a darn good
job of following the suggestions in a document hardly anybody
seems to observe.
the Linus Torvalds CodingStyle guidelines ...
-*- -*- -*- on indentation + etc. -*- -*- -*-
well almost all, except for those stinkin'...
I suppose even Linus Torvalds is entitled to err now and again.
How so you say? Tabs, me' bucko, stinkin' tabs! That, plus the
simplistic position regarding indentation espoused in that other-
wise excellent document.
-*- Rant On, and on -*-
Let's compare two approaches to the tab/indentation issue with a
small code sample using tabs then spaces. This snippet happens to
be the key to top's use of dynamic colors on many static screens,
while also ensuring screen width isn't exceeded so as to avoid
line wraps. We'll view just the first 40 columns, assuming one
wishes to occasionally provide comments to the right of actual
code (you do, don't you?).
Then YOU decide which approach makes the most SENSE!
Stinkin' Tabs versus Spaces: the Linus way
Hey, where'd my +----+----1----+----2----+----3----+----4+
many code lines | while (*sub_beg) { :
up-and-gone-to? | switch (*sub_end:
| case 0: :
Gosh, wonder if | \ Tabs Induced / :
Linus expects a | case 1: :
fellow to stick | + WASTE-Lands! + case 5: :
his comments on | :
the left side?! | + Not a Living + :
| :
Ever see source | + line-of-code + :
with not enough | :
whitespace; and | / To Be Found! \ :
this is better? | default::
| :
Oh lookie here, \ } :
there's just a hint of REAL code! ----> if (0 >= room) b:
/ } /* end: while 'subtrin:
+----------------------------------------+
Spaces versus Stinkin' Tabs: the other way
+----+----1----+----2----+----3----+----4+
Wow, now this is | while (*sub_beg) { :
Visible hackin'! | switch (*sub_end) { :
| case 0: :
Hmmm, wonder how | *(sub_end + 1) = '\0'; :
many programmers | case 1: case 2: case 3: case:
read those lines | case 5: case 6: case 7: case:
from the LEFT to | cap = Curwin->captab[(int:
the RIGHT? This | *sub_end = '\0'; :
"innovation" may | PUTP("%s%.*s%s", cap, roo:
2002-10-14 03:27:07 +05:30
possibly benefit | room -= (sub_end - sub_be:
those particular | sub_beg = ++sub_end; :
kinds of people, | break; :
you agree? Duh! | default: :
| ++sub_end; :
AND, there might | } :
even be room for | if (0 >= room) break; :
unseen comments! | } /* end: while 'subtrings' */ :
+----------------------------------------+
Gosh, I just don't KNOW -- it's such a TOUGH choice...
Oh you Stinkin' Tabs: correspondence, Who-Cares; documentation,
Oh-Alright; even scripts, Well-If-You-Must. But you have NO place
within the code-space of MY C-source listing! So be gone
already!!
In Summation...
- If you want to use tabs to the right of the code, go-for-it.
But PLEASE, not ever in the C-source code-space, thank-you-
kindly. Just use three little ol' spaces (exactly 3, no-more,
no-less) where you WOULD have stuck a stinkin' tab.
We'll get far more READABLE files, much less WAISTED precious
horizontal space, more consistent CURSORS and on, and ON, AND
ON! Plus, without those awful *the-devil's-own-handiwork*, the
aforementioned document need NEVER speak of their EVILS again.
- Lastly, since SPACES (not stinkin' tabs) are SO beneficial,
maybe we should use just a few more of 'em. Some of those C-
thingies are VERY sensitive -- they don't like being TOUCHED
by any other syntax element! Which ones? Why these guys:
braces, reserved words and binary operators
( it's the TRUTH, they told me themselves )
It's so EASY to keep 'em HAPPY! And lo-and-behold, the combi-
nation of <sp>thingy<sp> turns out to be a darn effective bug
repellent, too. So much so, one can actually code while
TOTALLY NUDE yet still avoid them ol' bug-bytes (sic-sic)!
step
down_from
me_punctilious
soap-box_once_again
[1 +5 +5 +5 = huh?]
## CUSTOMIZING the Sources ---------------------------------------------##
Listed below are the conditionals available should you wish to recompile
this top. The author's favorite is: PRETEND4CPUS.
That's the #define allowing you to simulate an SMP environment, and
(perhaps) impress your friends. It's currently set to display four
separate CPUs, but could easily be changed.
Caution: do NOT use this provision in an effort to impress someone
who truly possesses such a machine! The fact that all 4
CPUs show the same dynamic results will likely have the
opposite effect.
Enjoy...
//#define ATEOJ_REPORT /* report a bunch of stuff, at end-of-job */
//#define CASEUP_HEXES /* show any hex values in upper case */
//#define CASEUP_SCALE /* show scaled time/num suffix upper case */
//#define CASEUP_SUMMK /* show memory summary kilobytes with 'K' */
//#define POSIX_CMDLIN /* use '[ ]' for kernel threads, not '( )' */
//#define PRETEND2_5_X /* pretend we're linux 2.5.x (for IO-wait) */
2002-10-14 03:27:07 +05:30
//#define PRETEND4CPUS /* pretend we're smp with 4 ticsers (sic) */
//#define PRETENDNOCAP /* use a terminal without essential caps */
//#define SORT_SUPRESS /* *attempt* to reduce qsort overhead */
//#define USE_LIB_STA3 /* use lib status (3 ch) vs. proc_t (1 ch) */
//#define YIELDCPU_OFF /* hang on tight, DON'T issue sched_yield */
2002-10-14 03:27:07 +05:30
//#define WARN_NOT_SMP /* restrict '1' & 'I' commands to true smp */