On Mon, Jul 08, 2002 at 10:52:36AM -0700, Linus Torvalds wrote:
> - I'd associate each profiling event with a dentry/offset pair, simply
> because that's the highest-level thing that the kernel knows about and
> that is "static".
This makes sense, I think.
> - I'd suggest that the profiler explicitly mark the dentries it wants
> profiled, so that the kernel can throw away events that we're not
> interested in. The marking function would return a cookie to user
> space, and increment the dentry count (along with setting the
> "profile" flag in the dentry)
For a system-wide profiler, this needs to be /all/ dentries that get
mapped in with executable permissions, or we lose any mappings of shared
libraries we don't know about etc. Essentially, oprofile wants samples
against any dentry that gets mmap()ed with PROT_EXEC, so this marking
would really need to happen at mmap() time. Missing out on any dentry
profiles amounts to data loss in the system profile and has the
potential to mislead.
> - the "cookie" (which would most easily just be the kernel address of the
> dentry) would be the thing that we give to user-space (along with
> offset) on profile read. The user app can turn it back into a filename.
>
> Whether it is the original "mark this file for profiling" phase that saves
> away the cookie<->filename association, or whether we also have a system
> call for "return the path of this cookie", I don't much care about.
> Details, details.
>
> Anyway, what would be the preferred interface from user level?
oprofile currently receives eip-pid pairs, along with the necessary
syscall tracing info needed to reconstruct file offsets. The above
scheme removes the dependency on the pid, but this also unfortunately
throws away some useful information.
It is often useful to be able to separate out shared-library samples on
a per-process (and/or per-application) basis. Any really useful profile
buffer facility really needs to preserve this info, but just including
the raw pid isn't going to work when user-space can't reconstruct the
"name" of the pid (where "name" would be something "/bin/bash") because
the process exited in the meantime.
The same goes for kernel samples that happen in process context.
So this might work well in tandem with some global process-tree tracing
scheme, but I don't know what form that might take ...
(Then there are kernel modules, but that's probably best served by
patching modutils)
regards
john
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Mon Jul 15 2002 - 22:00:15 EST