Re: getrusage only partially working?
Re: getrusage only partially working?
- Subject: Re: getrusage only partially working?
- From: Mike Fischer <email@hidden>
- Date: Wed, 12 Dec 2007 19:59:36 +0100
Hi Terry,
Am 12.12.2007 um 18:03 schrieb Terry Lambert:
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".
Ah ok. That makes much more sense.
The BSD portion of the kernel does not maintain separate, parallel
state information for this Mach data, as doing so would be
prohibitively expensive.
Ok.
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.
What I fail to see is why tools like top(1) or ps(1) can get this
information while getrusage(2) can't. Obviously top and ps don't rely
on any parallel state information to be kept up to date. They can, it
seems, access the Mach data somehow. Given that all three are
implemented by Apple, why can't getrusage use the same underlying
data as well?
As for the performance, as a developer I would find a strongly worded
warning in the documentation to be much more helpful since I can then
decide if the function call is worth the performance penalty.
(Assuming of course that this penalty is incurred only when calling
getrusage, not otherwise.)
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.
Done: rdar://5643393
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.
OK, but getrusage is implemented by Apple as well. So it could be
kept in sync with the "combination of APIs, SPIs, and unstable
interfaces" just like top and ps.
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.
Understood. Not a very good workaround but certainly doable IMHO.
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.
See above.
Thanks for taking the time to explain!
Mike
--
Mike Fischer Softwareentwicklung, EDV-Beratung
Schulung, Vertrieb
Note: I read this list in digest mode!
Send me a private copy for faster responses.
_______________________________________________
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