pcp
[Top] [All Lists]

Re: PCP patch for top/libgtop conversion

To: Mike Mason <mmlnx@xxxxxxxxxx>
Subject: Re: PCP patch for top/libgtop conversion
From: Mark Goodwin <markgw@xxxxxxx>
Date: Wed, 25 Sep 2002 16:05:15 +1000 (EST)
Cc: pcp@xxxxxxxxxxx
In-reply-to: <3D90DA07.5090405@us.ibm.com>
Sender: pcp-bounce@xxxxxxxxxxx
On Tue, 24 Sep 2002, Mike Mason wrote:
>
> Here's my long awaited patch.  As you know, most of the changes were 
> made to support conversion of top and libgtop to use PCP.  I also made a 
> few small bug fixes, some in comments.  I added some "this code provided 
> by ..." comments which you can modify or remove if you'd like.  I'm not 
> sure how much of this type of comment you want to include.
> 
> The patch should be applied to the 2.2.2 source currently available from 
> the SGI PCP site.

I applied the patch to SGI internal top-of-tree, with a few mismatches
in pmda.c (expected since it's so huge and changes often) but otherwise
a clean patch.

> The changes to top and libgtop to use PCP are essentially done, but I 
> don't yet have a way to release them.  We go through a formal process at 
> IBM to get permission to contribute to outside projects.  I don't have 
> permission to contribute to procps or libgtop.  I'll work on that.

OK, let me know when that will proceed - we should talk to the relevant
maintainers.

> Please let me know of any changes you want me to make.

see comments below.

> Here's what was added and/or modified:
> 
> (new) Total idle time since boot
>       kernel.all.idletime

I've added help text for this

> (new) current # of user sessions
>       kernel.all.nusers

OK

> (new) Last pid used
>       kernel.all.lastpid

added help text

> (new) Filesystem blocksize from statfs()
>       filesys.blocksize

OK

> (new) Filesystem free space available to non-superusers from statfs()
>       filesys.avail

OK

> (modified) Per process command name
>       proc.psinfo.cmd
> (new) Per process command line from /proc/<pid>/cmdline
>       proc.psinfo.psargs

OK, though not sure if they are needed since the instance name for
each value already gives this info.

> 
> (new) Per process CPU number from /proc/<pid>/stat
>       proc.psinfo.processor

OK

> (new) Per process wait channel symbol name
>       proc.psinfo.wchan_s

Looks OK. I assume a zero length string means the processes is not blocked.
Also, my pmcd log reported :

        Warning: proc.psinfo.wchan_s symbol names may not be accurate!

> (new) Per process signal info from /proc/<pid>/status
>       proc.psinfo.signal_s
>       proc.psinfo.blocked_s
>       proc.psinfo.sigignore_s
>       proc.psinfo.sigcatch_s

Seems OK, however I'm getting possibly unexpected values for swapped
processes, e.g. for proc.psinfo.signal_s (pending signals mask) :

    inst [959 or "000959 (nfsd)"] value "fffffffffffffef8"

Did a signed int go negative or something?

> (new) Per process map info from /proc/<pid>/maps
>       proc.memory.maps

Seems OK. Did you need this to be specifically the same as cat /proc/*/maps
i.e. a very long string? Does it still work OK if the maps for a particular
process exceeds the copyout limit (one page)?

> (new) Per process memory info from /proc/<pid>/status
>       proc.memory.vmsize
>       proc.memory.vmlock
>       proc.memory.vmrss
>       proc.memory.vmdata
>       proc.memory.vmstack
>       proc.memory.vmexe
>       proc.memory.vmlib

The values for these metrics all seem to be off by
one line in /proc/PID/status. e.g. pminfo reports:

proc.memory.vmsize
    inst [20396 or "020396 -tcsh"] value 0 
proc.memory.vmlock
    inst [20396 or "020396 -tcsh"] value 1528
proc.memory.vmrss
    inst [20396 or "020396 -tcsh"] value 756
proc.memory.vmdata
    inst [20396 or "020396 -tcsh"] value 172
proc.memory.vmstack
    inst [20396 or "020396 -tcsh"] value 268
proc.memory.vmexe
    inst [20396 or "020396 -tcsh"] value 1456
proc.memory.vmlib: pmLookupDesc: Unknown or illegal metric identifier

but /proc/20396/status reports:

# cat /proc/20396/status | grep  '^Vm'
VmSize:     2804 kB
VmLck:         0 kB
VmRSS:      1528 kB
VmData:      756 kB
VmStk:       172 kB
VmExe:       268 kB
VmLib:      1456 kB

The fix is probably trivial ...

> (new) Per process user and group ids from /proc/<pid>/status
>       proc.id.uid
>       proc.id.euid
>       proc.id.suid
>       proc.id.fsuid
>       proc.id.gid
>       proc.id.egid
>       proc.id.sgid
>       proc.id.fsgid
> 
> (new) Per process user and group ids converted to names
>       proc.id.uid_nm
>       proc.id.euid_nm
>       proc.id.suid_nm
>       proc.id.fsuid_nm
>       proc.id.gid_nm
>       proc.id.egid_nm
>       proc.id.sgid_nm
>       proc.id.fsgid_nm

all seem to be OK

> (new) Semaphore limits from semctl()(needed by libgtop)
>       ipc.sem.max_semmap
>       ipc.sem.max_semid
>       ipc.sem.max_sem
>       ipc.sem.num_undo
>       ipc.sem.max_perid
>       ipc.sem.max_ops
>       ipc.sem.max_undoent
>       ipc.sem.sz_semundo
>       ipc.sem.max_semval
>       ipc.sem.max_exit
> 
> (new) Message queue limits from msgctl()(needed by libgtop)
>       ipc.msg.sz_pool
>       ipc.msg.mapent
>       ipc.msg.max_msgsz
>       ipc.msg.max_defmsgq
>       ipc.msg.max_msgqid
>       ipc.msg.max_msgseg
>       ipc.msg.num_smsghdr
>       ipc.msg.max_seg
> 
> (new) Shared memory limits from shmctl() (needed by libgtop)
>       ipc.shm.max_segsz
>       ipc.shm.min_segsz
>       ipc.shm.max_seg
>       ipc.shm.max_segproc
>       ipc.shm.max_shmsys

OK, all seem straight forward. 

thanks
-- Mark



<Prev in Thread] Current Thread [Next in Thread>