Subject: fixing ps to always display cpu time and start time.....
To: NetBSD Kernel Technical Discussion List <tech-kern@NetBSD.ORG>
From: Greg A. Woods <>
List: tech-kern
Date: 07/29/2001 16:46:55
As I've upgraded more and more machines that I manage I've begun to
really really really miss always having the process start time and cpu
usage always reported by "ps -u".

I'm suspecting it went away because "ps" no longer causes all the
"struct user" areas to be paged in as it scanned the proc table (though
I'm not really sure about this -- all I know is it works fine in 1.3.3
and earlier, maybe on the 1.4 branch, but not on the 1.5 branch, and
certainly not in -current any more).  (was this due to UVM?  or what?  I
don't see anything obvious about this in the most obvious CVS logs)

It would seem to me that moving p_stats into "struct proc" would be the
easiest and least disruptive change, though there are some internal-only
things in there that really don't have to always be around.

On i386 "struct pstat" as-is would add an additional 224 bytes per proc
entry, which can add up to a lot if ypu've got a large proc table
(almost 1MB on my system where maxproc = 4116, though that's less than
0.5% of the system's total memory, which isn't so bad).

If could be cut down to just 152 bytes if it were re-defined to only
include the necessary bits:

struct pstats {
	struct rusage p_ru;		/* stats for this proc */
	struct rusage p_cru;		/* sum of stats for reaped children */
	struct timeval p_start;		/* starting time */

(with all the other bits moved into "struct ustats", perhaps)

If we punted p_cru out too then that's just 80 more bytes per proc entry
(and usually less than 0.1% more of a system's memory used by the kernel):

struct pstats {
	struct rusage p_ru;		/* stats for this proc */
	struct timeval p_start;		/* starting time */

(I'd be tempted to simply eliminate "struct pstats" in the latter case
though and simply put p_ru and p_start directly in "struct proc".)

I definitely want those extra 80 bytes per entry to be in-core at all
times, and accessible by all processors, but I can live with 152 bytes,
or even 224 bytes, since even in the worst case it looks like it'll
almost certainly always be less than 0.5% more of total system memory
used on any appropriately configured machine.

							Greg A. Woods

+1 416 218-0098      VE3TCP      <>     <>
Planix, Inc. <>;   Secrets of the Weird <>