From: John L. <mo...@co...> - 2001-12-12 02:29:48
|
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 ... regards john -- "Take the ideas you find useful. Try not to get hung up on the labels." - Jonathan S. Shapiro |