On Tue, Dec 11, 2001 at 01:35:15AM -0800, jonathan bright wrote:
> i'm having problems figuring out which libc calls are producing
> what kernel load, and which application functions are producing
> what libc load.
yes, this is often a gray magic sort of thing.
> when i uncheck "profile kernel" in the gui, the time seems
> to complete disappear, as opposed to being reported in libc
> or my application. i would be really great if oprofile
> could be made to:
> 1- accumulate kernel in kernel, libc, and application,
> and have libc accumulate in libc and application, or
> 2- turn off kernel, and have accumulcation in libc or application,
> and then turn off libc, and have accumulation in application.
I'm not sure what you mean. If you want to determine e.g. the libc
samples used by your application, you can use the filter-pid or, in your
case, the filter-pgrp option.
We are currently ruminating on ways to allow an option to separate every
sample into per-process fields. As we use mmap(), there are address space
shortage and i/o bandwidth problems.
Philippe: I think we can lessen the first simply by doing LRU on our mmap() files
and unmapping old ones. The second problem is of more concern as we are
page-based - we need really good sparse array support essentially, but I don't
know of any open options ...
"Take the ideas you find useful. Try not to get hung up on the labels."
- Jonathan S. Shapiro