That was rather new code last time... the new top now runs much
better, so you don't have to give up Linux 2.2.xx to support the
2.5.xx kernel, etc.
The WOLK kernel needs a patch -- or rather, one less patch. :-)
The procps-2.x.x code silently gives bad output; it does NOT work.
http://procps.sf.net/
http://procps.sf.net/procps-3.0.4.tar.gz
------------ changes ------------
procps-3.0.3 --> procps-3.0.4
make top go faster
Linux 2.2.xx ELF note warning removed
only show IO-wait on recent kernels
fix top's SMP stats
fix top for "dumb" and "vt510" terminals
in top, limit the priority values to -99 ... 99
procps-3.0.2 --> procps-3.0.3
more "make install" fixes
lib CFLAGS working again
top.1 codes fixed
bad (int*) cast in top removed
top runs faster
libproc memory corruption fixed
rant moved out of top.1 man page
ability to SKIP installing things
fixed ps --sort crash
procps-3.0.1 --> procps-3.0.2
top defaults to the old layout
top defaults to sorting by %CPU
fix top for non-SMP 2.2.xx and 2.0.xx
new "make install" fixed
vmstat -a fixed
vmstat compiles with latest gcc-3.x
vmstat does 64-bit time
Albert D. Cahalan wrote:
> The procps-2.x.x code silently gives bad output; it does NOT work.
Can you be more specific? What bugs do you see?
I am wondering if Red Hat should integrate your procps if this is so?
On Sat, 19 Oct 2002, Jeff Garzik wrote:
> Albert D. Cahalan wrote:
> > The procps-2.x.x code silently gives bad output; it does NOT work.
>
>
> Can you be more specific? What bugs do you see?
>
> I am wondering if Red Hat should integrate your procps if this is so?
Hi,
Under RedHat 8, when two cpu intensive processes are running at nice 19
on my smp system, top will report both 100% cpu for both user and nice.
The same is true for 7.3.
With procps-3.0.4 this seems to be fixed. Although the 'hide threads'
code seems to be missing, or at least not working. It would be nice to
have both.
Just my $.02 USD,
Scott
Jeff Garzik writes:
> Albert D. Cahalan wrote:
>> The procps-2.x.x code silently gives bad output; it does NOT work.
>
> Can you be more specific? What bugs do you see?
In this one case:
There isn't error checking in the five_cpu_numbers function
to detect bad data. Not that bad data should ever happen; there
is a bug in the WOLK kernel.
In other cases:
Craig and I have been fixing bugs for years. Going down Red Hat's
bug list, I believe we've fixed these unclosed bugs:
35174 watch double-spaces long lines
40909 free does not return all swap space defined
53300 top + addition of i/o wait
53702 top, ps segmentation fault
54195 ps shouldn't truncate lines when outputting to a pipe
55862 top resource usage <-- more to come
57912 size argument doesn't work in ps <-- correctly fixed
74255 patch to top.c fixing spurious idle time percentage miscalculation
74692 type in online help
75354 sysctl variable problem when setting parameters on vlan inte
Plus we fixed the others (duplicated effort) and fixed a number
of things not reported to Red Hat. The debian-unstable users are
pretty clueful about reporting bugs.
> I am wondering if Red Hat should integrate your procps if this is so?
Red Hat should use procps 3, but not because of a problem in
the WOLK kernel. There are many other reasons to use procps 3.
Nice how SourceForge would go down right when I want to get to
the change logs. :-( There are two; when the site comes back
up you can try [Cc]hange[Ll]og(.html|.txt|) names to find it.
(only the recent stuff has a link off the front page)
http://procps.sf.net/
Obligatory linux-kernel discussion:
It's a POSIX and UNIX requirement to report per-process %cpu
over some undefined _recent_ time period. Linux does not
provide this info. Decaying averages like uptime(1) provides
would be great, maybe for 2, 10, and 60 seconds.
I could make vmstat way faster if the kernel would provide the
number of tasks that are running, swapped out, blocked, etc.
Right now vmstat has to examine every process in the system
just to count those up. Some of those are even tracked already,
such as nr_running in kernel.sched.c.
It'd be great to have an "adopted child" flag to mark processes
which have been reparented to init. This would make "ps f" better.
Also a flag for kapm-idled would be good. Note that these flags
have to be stable over time; the existing process flags have not
been stable and thus could not sanely be used.
Having a /proc/*/tty symlink would make procps run faster.
On Sat, 19 Oct 2002, Albert D. Cahalan wrote:
> > Can you be more specific? What bugs do you see?
> There isn't error checking in the five_cpu_numbers function
> to detect bad data. Not that bad data should ever happen; there
> is a bug in the WOLK kernel.
Guess why the iowait stats are initialised to 0 ? ;)
We know that user, system, nice and idle are present
in every kernel and we bail out with an error if we
get less than 4 values for the CPU stats.
> I could make vmstat way faster if the kernel would provide the
> number of tasks that are running, swapped out, blocked, etc.
I sent in a patch for that. I'll resend when Linus returns
from holidays.
cheers,
Rik
--
Bravely reimplemented by the knights who say "NIH".
http://www.surriel.com/ http://distro.conectiva.com/
Current spamtrap: <a href=mailto:"[email protected]">[email protected]</a>
Rik van Riel writes:
> On Sat, 19 Oct 2002, Albert D. Cahalan wrote:
>>> Can you be more specific? What bugs do you see?
>>
>> There isn't error checking in the five_cpu_numbers function
>> to detect bad data. Not that bad data should ever happen; there
>> is a bug in the WOLK kernel.
>
> Guess why the iowait stats are initialised to 0 ? ;)
>
> We know that user, system, nice and idle are present
> in every kernel and we bail out with an error if we
> get less than 4 values for the CPU stats.
The problem is not at all related to the IO-wait addition,
and no you don't bail out with an error... procps 3 does
bail out, elsewhere, causing the mistaken belief that procps 2
runs correctly on a WOLK kernel. That's wrong; no procps runs
correctly on a WOLK kernel.
I mentioned the issue merely to avoid bogus bug reports.
I don't want WOLK kernel users claiming that procps 2 works
and procps 3 not; the truth is that neither one can work
on a WOLK kernel.
>> I could make vmstat way faster if the kernel would provide the
>> number of tasks that are running, swapped out, blocked, etc.
>
> I sent in a patch for that. I'll resend when Linus returns
> from holidays.
Great.
[email protected] seems to have most of a patch for
the %CPU problem. (tracking the data, but not reporting it)
What about /proc/*/tty, an adopted-child flag, something for
the kapmd-idle problem, /proc/*/threads/* files, etc. ?