Hello,
Please find the answers below.
1.a.
I certainly don't find that any more readable.
The units are confusing too. For pageins, is that pages, kilobytes, or k/s?
The sizes of fields which were output in kilobytes are only scaled
to a human readable format, for example,
44.1G 9.9M 2T 199K
Scaling is done by repetitively dividing by 1024 for below fields.
memory{swap, free}, page{pi, po, fr, de}, executable, anonymous, filesystem
So for memory {swap/free} -> Kbytes, Mbytes, Gbytes, ...
Copying from man page,
//
page Report information about page faults and
paging activity. The information on each of
the following activities is given in units
per second.
pi kilobytes paged in
//
So for pages, page{pi, po, fr, de} - (xxx)bytes/second (kilo/mega/giga/tera/exa
bytes)
But page reclaims and minor faults, page { re, mf }
are scaled by repetitively dividing by 1000.
page reclaims - 50K == 50 * 1000 units/s
minor faults - 50K == 50 * 1000 units/s
In vmstat, as of now, pages are being converted to kilobytes as below.
Copying from vmstat.c
//
#define pgtok(a) ((a) * (pagesize >> 10))
//
1.b
** Why aren't the cpu fields "humanized"?
kthr - Report the number of kernel threads
page {sr} - pages scanned by clock algorithm
cpu - percentage usage of CPU time.
faults - Report the trap/interrupt rates (per second).
These are left untouched.
kthr, sr and faults can be scaled by repetitively dividing by 1000, though.
cpu gives the percentage usage of cpu time, so not a feasible idea to scale.
Preferred not to scale them.
1.c
*** > > vmstat -po memory,page,executable 2 2
OK, so what fields are allowed for the -o option? I didn't see
'executable' listed.
Agreed. Will clearly specify as below :
The fields that are allowed for the "o" option are :
kthr, memory, page, faults, cpu
for "-po" :
memory, page, executable, anonymous, filesystem
1.d
*** I'm not convinced that the -h is a good idea, though.
The humanisation is in vague for quite some time (Example df -hl ).
Its relevant in this case as well.
The existing default output can still be obtained.
1.e
*** It would be better if selecting fewer columns spread the display out so the
columns lined up, which would make it far more readable.
The outgrowth/shrinking of field values is random.
Its far more convenient to read them in prefixed form.
Best Regards,
Manjula
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://mail.opensolaris.org/pipermail/opensolaris-arc/attachments/20080521/4c972e1e/attachment.html>
