Re: getrusage only partially working?
Re: getrusage only partially working?
- Subject: Re: getrusage only partially working?
- From: Terry Lambert <email@hidden>
- Date: Wed, 12 Dec 2007 09:03:13 -0800
On Dec 12, 2007, at 12:21 AM, Mike Fischer <email@hidden> wrote:
Hi Terry,
Am 12.12.2007 um 03:27 schrieb Terry Lambert:
On Dec 11, 2007, at 7:26 AM, Mike Fischer wrote:
Hi!
For some reason I can't seem to get getrusage(2) to work the way I
expect it to under 10.4.11 on a PPC G5 machine (haven't tested on
other machines).
I expected the memory related fields to show values other than 0
which more or less correlate with the actual memory usage of the
application. But what I am seeing is values of 0 only in each of
these fields (ru_maxrss, ru_ixrss, ru_idrss, ru_isrss).
Probably I'm doing something wrong, but what?
Most of the information you are requesting in Mac information, and
you are requesting it using a BSD API.
Generally I don't see anything wrong with that. Why wouldn't I call
BSD APIs in a command line tool? (Also your sentence structure is
not entirely clear to me so I may be missing some of the meaning
here?)
Sorry, iPhone correction-itis. "is Mach information". The BSD
portion of the kernel does not maintain separate, parallel state
information for this Mach data, as doing so would be prohibitively
expensive.
As a result, the only way to get the information is to post-process
the corresponding Mach data, and to avoid repeated expense, this is
only done after process termination, to provide totals, rather than a
running tally.
The BSD API idea of the information will not be updated until the
process exits (see xnu/bsd/kern/kern_exit.c:proc_exit()).
Err, in that case how would the call ever work with the given option
RUSAGE_SELF?
Generally, it would not. Our command line (and GUI) performance tools
tend to use Mach, rather than BSD, APIs for reporting most information
like this, if that information needs to be collected at runtim, rather
than on a child process.
Seems like a chicken and egg problem to me: the info is updated when
the process exits but since the process has exited it can't call
getrusage any more. At the very least the man page could be a bit
more clear about this.
File a bug; most likely we will change the man page to deprecate use
of this call, and point you at our performance tools instead.
If you want this information while the process is running, you're
going to need link against the whole kernel and use unsupported APIs.
No thanks, I don't want the info that badly ;-) I was just
experimenting to see if I could access similar values to what top(1)
or Activity Monitor report inside my application. And since they can
do this while my app is running I thought the process itself should
be able to as well.
These tools use a combination of APIs, SPIs, and unstable interfaces
which can change from release to release, even in software updates.
The reason it's ok for us to do this is that when we modify the means
of getting the information, we are able to modify system supplied
tools in lock-step with kernel modifications, so the tools keep working.
This is the primary reason I suggested a popen of a "ps -o<list of
fields> -<scoping options>" would probably be a more or less portable
way of getting state information on processes. At least you know that
to keep certification, we have to keep supporting the options POSIX
requires, and if we change the way the ps program obtains information,
we'll change the ps program itself in lockstep with the kernel/line
changes.
Needless to say, this will end up being rather expensive, which is
why we don't export them via BSD in the first place.
Yeah, that makes sense. But given the documentation of getrusage my
expectations where different.
Should I file a bug? If so, against getrusage
You can; the most likely response, as noted above, will be to modify
the man page to tell you not to use it.
I understand people wanting to write their own performance tools, but
people who do this also need to understand that doing so will likely
tie them to the same constraints Apple has with regard to using SPIs
and unstable interfaces. This translates to them potentially having to
recompile their tools on each software update, just like we frequently
have to do, to keep them working, unless they wrap out tools.
-- Terry
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Darwin-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden