Skip Menu |
 

This queue is for tickets about the Proc-ProcessTable CPAN distribution.

Report information
The Basics
Id: 52530
Status: open
Priority: 0/
Queue: Proc-ProcessTable

People
Owner: Nobody in particular
Requestors: christian.boitel [...] gmail.com
Cc:
AdminCc:

Bug Information
Severity: (no value)
Broken in: (no value)
Fixed in: (no value)



Subject: time process statistics "truncated" under AIX
Date: Mon, 7 Dec 2009 15:29:33 +0100
To: bug-Proc-ProcessTable [...] rt.cpan.org
From: Christian BOITEL <christian.boitel [...] gmail.com>
Download (untitled) / with headers
text/plain 1.5k
Process execution stats are reported by AIX using two long values: tv_sec and tv_usec. When looking at the time consumption reported by module under AIX, we found they were all a factor of 100 meaning precision was a second. In aix_getprocs.c or aix.c, under bless_procs function, tv_sec and tv_usec members are combined to produce a unique time value which is stored in a long (i.e. utime, stime, cutime or cstime). Due to the long cast, these values are finally reflecting only the tv_sec part: the tv_usec part is lost. Later, the long values are multiplied by 100 (uselessly) By simply declaring utime, stime, cutime or cstime as double instead of long at the beginning of the bless_procs function, the tv_usec part is no longer lost and module will report cpu consumption with a better precision. Example: --- Proc-ProcessTable-0.45.original/os/aix_getprocs.c 2003-05-28 08:41:15.000000000 +0200 +++ Proc-ProcessTable-0.45.patched/os/aix_getprocs.c 2009-12-03 17:54:54.000000000 +0100 @@ -112,31 +112,31 @@ void bless_procs(struct procsinfo64 *procs, int count) { int index; char cmndline[ARG_MAX]; char comm[ARG_MAX]; char pctmem[PCT_LENGTH]; char pctcpu[PCT_LENGTH]; char state[STATE_LENGTH]; char *c = NULL; struct procsinfo64 *curproc = NULL; struct procsinfo curproc_for_getargs; int zombie; int done; - long utime, stime, cutime, cstime; + double utime, stime, cutime, cstime; /* initialize */ Zero(&curproc_for_getargs, 1, struct procsinfo);
Download (untitled) / with headers
text/plain 343b
*oops* - I didn't see it while I modified that for AIX. Your patch looks like the problem persists on 32-bit as well as on 64-bit, didn't it? I'm working on cleaning up the internals of the module to get it more flexible for extensions (especially *BSD need rework ...). I hope I get it finished this year - but maybe it's getting January ...
Subject: Re: [rt.cpan.org #52530] time process statistics "truncated" under AIX
Date: Tue, 8 Dec 2009 16:50:46 +0100
To: bug-Proc-ProcessTable [...] rt.cpan.org
From: Christian BOITEL <christian.boitel [...] gmail.com>
Download (untitled) / with headers
text/plain 1.2k
In fact, if you refactor things, I would suggest to have a global approach by ensuring module does return consistent data across operating systems => time related process entries on AIX returns a long of tenth of seconds (e.g. 19987 means 199 seconds and 870ms) while it is a float of seconds on Linux (e.g. 199.87) => same on memory related values : number of pages on some OS, Kb on some other: why not returning only Kb for all ? => ... I was also wondering the need of using C code since we could write things in native perl using unpack to extract data from /proc/xxx/yyyy files => this would make the module more easily portable ($^O usage would allow to switch between multiple implementations in different sub-modules) Finally, I only tested my patch on a 32 bit perl (the one provided by the OS) with IBM C compiler. 2009/12/8 Jens Rehsack via RT <bug-Proc-ProcessTable@rt.cpan.org> Show quoted text
> <URL: https://rt.cpan.org/Ticket/Display.html?id=52530 > > > *oops* - I didn't see it while I modified that for AIX. Your patch looks > like the problem persists on 32-bit as well as on 64-bit, didn't it? > > I'm working on cleaning up the internals of the module to get it more > flexible for extensions (especially *BSD need rework ...). > I hope I get it finished this year - but maybe it's getting January ... >
Download (untitled) / with headers
text/plain 422b
Good points - I didn't had that in mind, but now it'll be January or February ;) But you're right - this should be cleared over all systems. To your question: why using XS where native perl would be ok: I don't know, and I'm searching for a good way to being able to use perl implementations as well as XS. If you're interested in discussing this, please open another RT (to have the discussion public) or send me a mail.


This service is sponsored and maintained by Best Practical Solutions and runs on Perl.org infrastructure.

Please report any issues with rt.cpan.org to rt-cpan-admin@bestpractical.com.