Procps 2.0.10
8 Oct 2002
Procps is the package containing various system monitoring tools, like
ps, top, vmstat, free, kill, sysctl, uptime and more. After a long
period of inactivity procps maintenance is active again and suggestions,
bugreports and patches are always welcome on the procps list.
The plan is to release a procps 2.1.0 around the time the 2.6.0 kernel
comes out, with regular releases until then. Code cleanups and all kinds
of enhancements are welcome.
You can download procps 2.0.10 from:
http://surriel.com/procps/procps-2.0.10.tar.bz2
If you have feedback (or patches) for the procps team, feel free to
mail us at:
[email protected]
NEWS for version 2.0.10 of procps
* fix memory size overflow in ps (Anton Blanchard)
* add iowait statistics to top (Rik van Riel)
* update top help text (Denis Vlasenko)
* fix jumpy percentage formatting in top (Denis Vlasenko)
* fix some newer gcc compiler warnings (Denis Vlasenko)
* by default, do not show threads in ps or top - you can use the
`-m' flag in ps or the `H' key in top to show them (Robert Love)
Rik
--
A: No.
Q: Should I include quotations after my reply?
http://www.surriel.com/ http://distro.conectiva.com/
On 2002.10.08 Rik van Riel wrote:
> Procps 2.0.10
> 8 Oct 2002
>
>
>Procps is the package containing various system monitoring tools, like
>ps, top, vmstat, free, kill, sysctl, uptime and more. After a long
>period of inactivity procps maintenance is active again and suggestions,
>bugreports and patches are always welcome on the procps list.
>
>The plan is to release a procps 2.1.0 around the time the 2.6.0 kernel
>comes out, with regular releases until then. Code cleanups and all kinds
>of enhancements are welcome.
>
>
>You can download procps 2.0.10 from:
>
> http://surriel.com/procps/procps-2.0.10.tar.bz2
This makes CPU percentages stay aligned in column when some of them
reach 100%:
--- top.c.orig 2002-10-08 15:28:10.000000000 +0200
+++ top.c 2002-10-08 16:18:59.000000000 +0200
@@ -1700,8 +1700,8 @@
cpu_mapping
[i];
printf
- ("CPU%d states: %2d%s%-d%% user, %2d%s%-d%% system,"
- " %2d%s%-d%% nice, %2d%s%-d%% iowait, %2d%s%-d%% idle",
+ ("CPU%d: %3d%s%-d%% user, %3d%s%-d%% system,"
+ " %3d%s%-d%% nice, %3d%s%-d%% iowait, %3d%s%-d%% idle",
cpumap,
trimzero(u_ticks - u_ticks_o [i] + n_ticks - n_ticks_o [i]) * 100 / t_ticks,
decimal_point,
It also kills the 'states' part, things are beginning to spread past 80
columns...is it very important ?
I am gettin also strange outputs sometimes, with a ton of digits in decimal
parts. Sample before my patch:
CPU0 states: 0,0% user, 0,6% system, 0,0% nice, 4,1070653% iowait, 0,109% idle
CPU1 states: 0,1% user, 0,1% system, 0,0% nice, 4,1070653% iowait, 0,113% idle
And after:
CPU0: 0,12% user, 0,5% system, 0,0% nice, 99,1357% iowait, 0,489% idle
CPU1: 0,13% user, 0,15% system, 0,0% nice, 99,1357% iowait, 0,478% idle
--
J.A. Magallon <[email protected]> \ Software is like sex:
werewolf.able.es \ It's better when it's free
Mandrake Linux release 9.0 (dolphin) for i586
Linux 2.4.20-pre9-jam1 (gcc 3.2 (Mandrake Linux 9.0 3.2-1mdk))
On Tue, 8 Oct 2002, J.A. Magallon wrote:
> It also kills the 'states' part, things are beginning to spread past 80
> columns...is it very important ?
Yes, things should stay within 80 lines.
> I am gettin also strange outputs sometimes, with a ton of digits in
> decimal parts.
Wait... I remember fixing that bug. On 2.4 kernels iowait
should always be 0.0% and it always is 0.0% here.
I have no idea why it's displaying a wrong value on your
system, unless you somehow managed to run against a wrong
libproc.so (shouldn't happen).
regards,
Rik
--
A: No.
Q: Should I include quotations after my reply?
http://www.surriel.com/ http://distro.conectiva.com/
On 2002.10.08 Rik van Riel wrote:
>On Tue, 8 Oct 2002, J.A. Magallon wrote:
>
>> It also kills the 'states' part, things are beginning to spread past 80
>> columns...is it very important ?
>
>Yes, things should stay within 80 lines.
>
You can also kill the commas ',', they look not so important:
CPU0: 0,0% user 0,0% system 0,0% nice 0,0% iowait 100,0% idle
CPU1: 0,4% user 0,3% system 0,0% nice 0,0% iowait 98,3% idle
>> I am gettin also strange outputs sometimes, with a ton of digits in
>> decimal parts.
>
>Wait... I remember fixing that bug. On 2.4 kernels iowait
>should always be 0.0% and it always is 0.0% here.
>
>I have no idea why it's displaying a wrong value on your
>system, unless you somehow managed to run against a wrong
>libproc.so (shouldn't happen).
>
werewolf:/lib# which top
/usr/bin/top
werewolf:/lib# ldd `which top`
libproc.so.2.0.10 => /lib/libproc.so.2.0.10 (0x1557b000)
libncurses.so.5 => /lib/libncurses.so.5 (0x15589000)
libc.so.6 => /lib/i686/libc.so.6 (0x155ce000)
libgpm.so.1 => /usr/lib/libgpm.so.1 (0x156ee000)
/lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x15556000)
???
Will take a look.
By.
--
J.A. Magallon <[email protected]> \ Software is like sex:
werewolf.able.es \ It's better when it's free
Mandrake Linux release 9.0 (dolphin) for i586
Linux 2.4.20-pre9-jam1 (gcc 3.2 (Mandrake Linux 9.0 3.2-1mdk))
On 2002.10.08 Rik van Riel wrote:
>On Tue, 8 Oct 2002, J.A. Magallon wrote:
>
>> It also kills the 'states' part, things are beginning to spread past 80
>> columns...is it very important ?
>
>Yes, things should stay within 80 lines.
>
>> I am gettin also strange outputs sometimes, with a ton of digits in
>> decimal parts.
>
>Wait... I remember fixing that bug. On 2.4 kernels iowait
>should always be 0.0% and it always is 0.0% here.
>
>I have no idea why it's displaying a wrong value on your
>system, unless you somehow managed to run against a wrong
>libproc.so (shouldn't happen).
>
It looks like the 2 first screenshots show buggy data:
First:
CPU0: 0,1% user 0,1% system 0,0% nice 99,18% iowait 0,103% idle
CPU1: 0,0% user 0,4% system 0,0% nice 99,18% iowait 0,101% idle
Second:
CPU0: 0,15% user 0,4% system 0,0% nice 4,1070639% iowait 0,434% idle
CPU1: 0,13% user 0,7% system 0,0% nice 4,1070639% iowait 0,433% idle
Third:
CPU0: 3,1% user 2,3% system 0,0% nice 0,0% iowait 94,0% idle
CPU1: 3,3% user 2,0% system 0,0% nice 0,0% iowait 94,1% idle
Always the same, does not depend on interval. Samples above were taken with
top -d100.
Hope this helps.
--
J.A. Magallon <[email protected]> \ Software is like sex:
werewolf.able.es \ It's better when it's free
Mandrake Linux release 9.0 (dolphin) for i586
Linux 2.4.20-pre9-jam1 (gcc 3.2 (Mandrake Linux 9.0 3.2-1mdk))
On Tue, 8 Oct 2002, J.A. Magallon wrote:
> >should always be 0.0% and it always is 0.0% here.
> >
> >I have no idea why it's displaying a wrong value on your
> >system, unless you somehow managed to run against a wrong
> >libproc.so (shouldn't happen).
>
> It looks like the 2 first screenshots show buggy data:
Yup, that's the bug I fixed friday. Wait a moment, I fixed
it for five_cpu_numbers(), but probably not for the SMP CPU
code in top.c itself ...
I'll fix this one after lunch.
thanks,
Rik
--
A: No.
Q: Should I include quotations after my reply?
http://www.surriel.com/ http://distro.conectiva.com/
On 2002.10.08 Rik van Riel wrote:
>On Tue, 8 Oct 2002, J.A. Magallon wrote:
>
>> It also kills the 'states' part, things are beginning to spread past 80
>> columns...is it very important ?
>
>Yes, things should stay within 80 lines.
>
>> I am gettin also strange outputs sometimes, with a ton of digits in
>> decimal parts.
>
>Wait... I remember fixing that bug. On 2.4 kernels iowait
>should always be 0.0% and it always is 0.0% here.
>
>I have no idea why it's displaying a wrong value on your
>system, unless you somehow managed to run against a wrong
>libproc.so (shouldn't happen).
>
Perhaps it is the percentage-mod plays. With this (calculate percentage in
0.1% units and then /10 and %10, I do not get that strange output). Perhaps
it was gcc-3.2 optimizing things, and it eats this better. It also guarantees
that decimal part never has more than 1 digit (%10 thing):
--- top.c.orig 2002-10-08 15:28:10.000000000 +0200
+++ top.c 2002-10-08 17:21:24.000000000 +0200
@@ -1691,6 +1691,8 @@
i, __LINE__);
break;
} else {
+ int u_delta, s_delta, n_delta, io_delta, i_delta, un_delta;
+
t_ticks = (u_ticks + s_ticks + i_ticks + n_ticks + io_ticks)
- (u_ticks_o[i] + s_ticks_o[i] + i_ticks_o[i] + n_ticks_o[i] + io_ticks_o[i]);
if (Irixmode)
@@ -1699,25 +1701,21 @@
cpumap =
cpu_mapping
[i];
+ u_delta = (trimzero(u_ticks - u_ticks_o[i])*1000)/t_ticks;
+ s_delta = (trimzero(s_ticks - s_ticks_o[i])*1000)/t_ticks;
+ n_delta = (trimzero(n_ticks - n_ticks_o[i])*1000)/t_ticks;
+ io_delta = (trimzero(io_ticks - io_ticks_o[i])*1000)/t_ticks;
+ i_delta = (trimzero(i_ticks - i_ticks_o[i])*1000)/t_ticks;
+ un_delta = (trimzero(u_ticks - u_ticks_o[i]+n_ticks - n_ticks_o[i])*1000)/t_ticks;
printf
- ("CPU%d states: %2d%s%-d%% user, %2d%s%-d%% system,"
- " %2d%s%-d%% nice, %2d%s%-d%% iowait, %2d%s%-d%% idle",
+ ("CPU%d: %3d%s%-d%% user %3d%s%-d%% system"
+ " %3d%s%-d%% nice %3d%s%-d%% iowait %3d%s%-d%% idle",
cpumap,
- trimzero(u_ticks - u_ticks_o [i] + n_ticks - n_ticks_o [i]) * 100 / t_ticks,
- decimal_point,
- trimzero(u_ticks - u_ticks_o [i]) * 100 % t_ticks / 100,
- trimzero(s_ticks - s_ticks_o [i]) * 100 / t_ticks,
- decimal_point,
- trimzero(s_ticks - s_ticks_o [i]) * 100 % t_ticks / 100,
- trimzero(n_ticks - n_ticks_o [i]) * 100 / t_ticks,
- decimal_point,
- trimzero(n_ticks - n_ticks_o [i]) * 100 % t_ticks / 100,
- trimzero(io_ticks - io_ticks_o [i]) * 100 / t_ticks,
- decimal_point,
- trimzero(io_ticks - io_ticks_o [i]) * 100 % t_ticks / 100,
- trimzero(i_ticks - i_ticks_o [i]) * 100 / t_ticks,
- decimal_point,
- trimzero(i_ticks - i_ticks_o [i]) * 100 % t_ticks / 100);
+ un_delta/ 10, decimal_point, un_delta% 10,
+ s_delta / 10, decimal_point, s_delta % 10,
+ n_delta / 10, decimal_point, n_delta % 10,
+ io_delta/ 10, decimal_point, io_delta% 10,
+ i_delta / 10, decimal_point, i_delta % 10);
s_ticks_o[i] = s_ticks;
u_ticks_o[i] = u_ticks;
n_ticks_o[i] = n_ticks;
And looks cleaner...;)
--
J.A. Magallon <[email protected]> \ Software is like sex:
werewolf.able.es \ It's better when it's free
Mandrake Linux release 9.0 (dolphin) for i586
Linux 2.4.20-pre9-jam1 (gcc 3.2 (Mandrake Linux 9.0 3.2-1mdk))
On 2002.10.08 Rik van Riel wrote:
>On Tue, 8 Oct 2002, J.A. Magallon wrote:
>
>> >should always be 0.0% and it always is 0.0% here.
>> >
>> >I have no idea why it's displaying a wrong value on your
>> >system, unless you somehow managed to run against a wrong
>> >libproc.so (shouldn't happen).
>>
>> It looks like the 2 first screenshots show buggy data:
>
>Yup, that's the bug I fixed friday. Wait a moment, I fixed
>it for five_cpu_numbers(), but probably not for the SMP CPU
>code in top.c itself ...
>
>I'll fix this one after lunch.
>
Oops...
I swear, I had not seen five_cpu_numbers when I sent you the patch
about 0.1%...
--
J.A. Magallon <[email protected]> \ Software is like sex:
werewolf.able.es \ It's better when it's free
Mandrake Linux release 9.0 (dolphin) for i586
Linux 2.4.20-pre9-jam1 (gcc 3.2 (Mandrake Linux 9.0 3.2-1mdk))
libgpm is present because your libncurses has been
linked with it.
you can use -lcurses -ltermcap insted (if you have old curses installed)
On Tue, 8 Oct 2002, J.A. Magallon wrote:
> Date: Tue, 8 Oct 2002 16:43:28 +0200
> From: J.A. Magallon <[email protected]>
> To: Rik van Riel <[email protected]>
> Cc: [email protected], [email protected]
> Subject: Re: [ANNOUNCE] procps 2.0.10
>
>
> On 2002.10.08 Rik van Riel wrote:
> >On Tue, 8 Oct 2002, J.A. Magallon wrote:
> >
> >> It also kills the 'states' part, things are beginning to spread past 80
> >> columns...is it very important ?
> >
> >Yes, things should stay within 80 lines.
> >
>
> You can also kill the commas ',', they look not so important:
>
> CPU0: 0,0% user 0,0% system 0,0% nice 0,0% iowait 100,0% idle
> CPU1: 0,4% user 0,3% system 0,0% nice 0,0% iowait 98,3% idle
>
> >> I am gettin also strange outputs sometimes, with a ton of digits in
> >> decimal parts.
> >
> >Wait... I remember fixing that bug. On 2.4 kernels iowait
> >should always be 0.0% and it always is 0.0% here.
> >
> >I have no idea why it's displaying a wrong value on your
> >system, unless you somehow managed to run against a wrong
> >libproc.so (shouldn't happen).
> >
>
> werewolf:/lib# which top
> /usr/bin/top
> werewolf:/lib# ldd `which top`
> libproc.so.2.0.10 => /lib/libproc.so.2.0.10 (0x1557b000)
> libncurses.so.5 => /lib/libncurses.so.5 (0x15589000)
> libc.so.6 => /lib/i686/libc.so.6 (0x155ce000)
> libgpm.so.1 => /usr/lib/libgpm.so.1 (0x156ee000)
> /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x15556000)
>
> ???
>
> Will take a look.
>
> By.
>
> --
> J.A. Magallon <[email protected]> \ Software is like sex:
> werewolf.able.es \ It's better when it's free
> Mandrake Linux release 9.0 (dolphin) for i586
> Linux 2.4.20-pre9-jam1 (gcc 3.2 (Mandrake Linux 9.0 3.2-1mdk))
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
On Tue, 8 Oct 2002, J.A. Magallon wrote:
> >Yup, that's the bug I fixed friday. Wait a moment, I fixed
> >it for five_cpu_numbers(), but probably not for the SMP CPU
> >code in top.c itself ...
>
> I swear, I had not seen five_cpu_numbers when I sent you the patch
> about 0.1%...
But that code is used on UP systems. I forgot to do the same
fix for SMP...
Rik
--
A: No.
Q: Should I include quotations after my reply?
http://www.surriel.com/ http://distro.conectiva.com/
Hey, I just saw the recent announcement of procps-3.0.1 on the mailing
list by the procps.sourceforge.net team, what is the status of these two
projects, there are features in each that are very nice, the versioning is
confusing, and inconsistant, and the package names are the same...
Kinda hoping to learn which tree a distribution developer should follow,
etc.
TIA,
Brandon Low
Gentoo Linux Kernel Release Manager
p.s. please CC
On Tue, 10/08/02 at 10:35:40 -0300, Rik van Riel wrote:
> Procps 2.0.10
> 8 Oct 2002
>
>
> Procps is the package containing various system monitoring tools, like
> ps, top, vmstat, free, kill, sysctl, uptime and more. After a long
> period of inactivity procps maintenance is active again and suggestions,
> bugreports and patches are always welcome on the procps list.
>
> The plan is to release a procps 2.1.0 around the time the 2.6.0 kernel
> comes out, with regular releases until then. Code cleanups and all kinds
> of enhancements are welcome.
>
>
> You can download procps 2.0.10 from:
>
> http://surriel.com/procps/procps-2.0.10.tar.bz2
>
> If you have feedback (or patches) for the procps team, feel free to
> mail us at:
>
> [email protected]
>
>
> NEWS for version 2.0.10 of procps
>
> * fix memory size overflow in ps (Anton Blanchard)
> * add iowait statistics to top (Rik van Riel)
> * update top help text (Denis Vlasenko)
> * fix jumpy percentage formatting in top (Denis Vlasenko)
> * fix some newer gcc compiler warnings (Denis Vlasenko)
> * by default, do not show threads in ps or top - you can use the
> `-m' flag in ps or the `H' key in top to show them (Robert Love)
>
>
>
> Rik
> --
> A: No.
> Q: Should I include quotations after my reply?
>
> http://www.surriel.com/ http://distro.conectiva.com/
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
On Thu, 10 Oct 2002, Brandon Low wrote:
> Hey, I just saw the recent announcement of procps-3.0.1 on the mailing
> list by the procps.sourceforge.net team, what is the status of these two
> projects, there are features in each that are very nice, the versioning is
> confusing, and inconsistant, and the package names are the same...
>
> Kinda hoping to learn which tree a distribution developer should follow,
> etc.
Simple: Albert's one is, well, Albert's. If it gets into sarge, procps
gets on hold on my boxen, so I'm not too concerned...
I would (read: will) go with Rik's variant - unlike Albert he got taste.
YMMV.
On Thu, 10 Oct 2002, Brandon Low wrote:
> Hey, I just saw the recent announcement of procps-3.0.1 on the mailing
> list by the procps.sourceforge.net team, what is the status of these two
> projects,
Albert Cahalan's procps seems to be focussed on rewriting
and improving procps.
The procps project I'm maintaining is more focussed on
supporting the latest stats exported by 2.5. I hope to
get some time to clean up the source code, too...
regards,
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>