Hi Stan,
----- Original Message -----
> The values I am seeing on linux for proc.psinfo.*time seem suspicious.
>
> # Get utime, stime directly
>
> cat /proc/26048/stat | awk '{print $14,$15}'
> 5 4
>
> # quite different results from pminfo (massaged with awk):
>
> pminfo -dtTf proc.psinfo | awk '/^proc/ {X=$1} /26048/ {print X,$0}' |
> grep -v awk | grep time
> ...
> proc.psinfo.utime inst [26048 or "026048 bash"] value
> 18446744073709546616
Hmmm, very suspect, and right at the 64-bit limit for all of them.
(gdb) p (unsigned long long)-1
$3 = 18446744073709551615
> ...
> Thoughts?
>
What architecture are you on there? For me on a rhel6-based x86_64
box, I'm not seeing similar behaviour - values looks sensible here.
The spot where I would punt that something is going funky would be in
the src/pmdas/linux_proc/pmda.c fetch callback (proc_fetchCallBack) -
some judicious logging or quality time in gdb might reveal the cause,
this spot in particular at around line 970:
case PROC_PID_STAT_UTIME:
case PROC_PID_STAT_STIME:
case PROC_PID_STAT_CUTIME:
case PROC_PID_STAT_CSTIME:
/*
* unsigned jiffies converted to unsigned milliseconds
*/
if ((f = _pm_getfield(entry->stat_buf, idp->item)) == NULL)
return PM_ERR_INST;
sscanf(f, "%lu", &ul);
_pm_assign_ulong(atom, 1000 * (double)ul / hz);
break;
Maybe dump out the string returned in "f" there to see if it matches
up with expectations, and if so follow through the transformation on
that _pm_assign_ulong line calculation. Perhaps the hz value isn't
initialised, somehow?
cheers.
--
Nathan
|