Well, everybody judges the usefulness of top differently. But I think a
time of 350ms (which is about 12 million processor cycles and much more
instructions) is waaay too long to display a few task statistics.
> takes 0.99% of the processor. And on the Celeron/338 I'm using as a
> workstation, it takes a princely .098% to do the same.
Are you sure that you are measuring this correctly? This is a serious
question: cpu time measurements are very incorrect (at least under
linux). My very crude measurement gives a lower bound (module system
load).
> of the badly designed proc displays which can't officially change
> but which do change enough to make upgrading to a new release
> a little more annoying] but performance doesn't leap out and
> grab me.
Then have a look at what people run on their desktops. Have a look at how
many people can be logged on to a machine, all with their desktop. These
very small times quickly sum up to a substantial amount of time.
As it is, /proc gives hundreds of pieces of information scattered about
many places, in a very inconsistent way (for example, how can I find the
statistics of my fifth harddisk? I can't find a place in proc...).
/proc is a nice place for things like cpuinfo, modules, partitions, uptime
and much more. But I fail to see the advantage of information that can
only be parsed by specialised programs ("number graves") anyway to be
published in /proc, so that it is ultra-slow to access.
--
-----==- |
----==-- _ |
---==---(_)__ __ ____ __ Marc Lehmann +--
--==---/ / _ \/ // /\ \/ / pcg@opengroup.org |e|
-=====/_/_//_/\_,_/ /_/\_\ XX11-RIPE --+
The choice of a GNU generation |
|
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/