Main Entry Point to hwpmc?
ajray
I'm trying to figure out the general workflow of tasks through the
PMCTools. I have been trying to Read The Fine Manual (the source) and
this is what I think I've found:
The hwpmc module is (overly simplictically) a series of internal data
structures, functions and hooks that is loaded into the kernel, and is
not it's own program or process. For a while now I guess I've been
looking for the primary 'loop' where it would loop infinitely awaiting
requests, which would be the main entry point.
while (TRUE) {
get_hwpmc_call();
...
} /* go back to get next call */
It seems this is not the case, so from what I can tell the kernel
catches calls/messges, and then uses hooks/functions to execute the
proper hwpmc code in response. So the closest thing I've found to a
'main entry' to hwpmc is the pmc_syscall_handler in hwpmc_mod.c:
http://fxr.watson.org/fxr/source/dev/hwpmc/hwpmc_mod.c?im=excerpts#L2664
Please correct me if I'm wrong, and thanks in advance,
~Alex
PS for those that dont know, I'm currently working on a port of
PMCTools to Minix. Since its a microkernel, hwpmc needs to be its own
process, but I'm working on a 'pmc server' that hwpmc can load into as
a module. This allows the majority of the code to run unmodified
(which means I can take advantage of later versions of PMCTools)
Joseph Koshy
Hi,
> Hello again,
>
> I'm trying to figure out the general workflow of tasks through the
> PMCTools. I have been trying to Read The Fine Manual (the source) and
> this is what I think I've found:
> The hwpmc module is (overly simplictically) a series of internal data
> structures, functions and hooks that is loaded into the kernel, and is
> not it's own program or process. For a while now I guess I've been
> looking for the primary 'loop' where it would loop infinitely awaiting
> requests, which would be the main entry point.
> while (TRUE) {
> get_hwpmc_call();
> ...
> } /* go back to get next call */
>
> It seems this is not the case, so from what I can tell the kernel
> catches calls/messges, and then uses hooks/functions to execute the
> proper hwpmc code in response. So the closest thing I've found to a
> 'main entry' to hwpmc is the pmc_syscall_handler in hwpmc_mod.c:
> http://fxr.watson.org/fxr/source/dev/hwpmc/hwpmc_mod.c?im=excerpts#L2664
>
> Please correct me if I'm wrong, and thanks in advance,
> PS for those that dont know, I'm currently working on a port of
> PMCTools to Minix. Since its a microkernel, hwpmc needs to be its own
> process, but I'm working on a 'pmc server' that hwpmc can load into as
> a module. This allows the majority of the code to run unmodified
> (which means I can take advantage of later versions of PMCTools)
You are correct about the fact that there is no "main loop" in
hwpmc(4). Instead, at a given point of time there could be multiple
"execution contexts" active inside hwpmc(4).
Here are some ways hwpmc(4) could be entered:
* Direct system calls:
- A thread in a process may invoke a PMC related system call (see
pmc_syscall_handler()).
* Hook calls from the "top-half" of the kernel:
- A thread may be in the process of fork()'ing or exit()'ing and
could execute hwpmc(4) hook code as a consequence.
- A thread invoking kldload()/kldunload(), or mmap()/munmap() would
similarly execute hwpmc(4) hook code.
* Hook calls from restricted kernel contexts:
- A thread belonging to a process being tracked by hwpmc(4) could be
context switching in (or out) of the CPU, and could potentially
execute hwpmc(4) code.
* Execution in an NMI context:
- The CPU could execute hwpmc(4) code while servicing an NMI raised
by a PMC.
These execution scenarios could be "stacked".
For example, consider a thread in a process being tracked by hwpmc(4)
that is servicing a system call such as fork(). While this thread is
executing hook code inside hwpmc(4), it could be chosen by the
scheduler for a pre-emptive context switch. This would cause
execution to re-enter hwpmc(4), to perform context-switch related
processing. At this point a PMC configured for sampling could
interrupt the CPU, leading to the CPU executing hwpmc(4) code in an
NMI context.
On SMP machines these scenarios could be occurring on multiple CPUs
concurrently.
Hope this clarifies,
Koshy
George Neville-Neil
I have noticed that when I use a relative path to a program after the
pmcstat command that
I do not wind up with output when I use pmcstat -R /tmp/foo -g. If I
use the full path
in the command used to capture events it works as I expect it to.
Is that a known bug or?
Best,
George
Fabien Thomas
The vfs layer does not have the entry in cache when relative path is
used.
On head it works for some sample tested but it works sometimes only on
stable_7.
Doing a userland name resolve before executing the program put it in
cache.
I've added a note in the man page for that.
Kind regards,
Fabien
Le 12 juin 09 à 17:59, George Neville-Neil a écrit :
Joseph Koshy
> Yes its a known "bug". The vfs layer does not have the entry in
> cache when relative path is used. On head it works for some sample
> tested but it works sometimes only on stable_7. Doing a userland
> name resolve before executing the program put it in cache. I've
> added a note in the man page for that.
hwpmc(4) uses vn_fullpath(9) on the vnode of the file being executed
to retrieve a name for it in the file system. From the symptoms
described, vn_fullpath(9) may not be working correctly in FreeBSD
7-STABLE.
I've created a tracker item:
http://code.google.com/p/pmctools/issues/detail?id=22
Koshy
Alexander Ray
I'm running into this sort of issue in porting to minix (minix vfs does not have name cache).
~Alex
Joseph Koshy
> What is the full path vital for in hwpmc(4)?
> I'm running into this sort of issue in porting to minix (minix vfs
> does not have name cache).
The kernel works with pointers to vnode descriptors (see "struct
vnode" in the sources).
However, the tools running in user mode need a (filesystem) path name
to work with.
In the FreeBSD kernel we have the vn_fullpath(9) function that
translates a vnode pointer back to a pathname (when it can) and
hwpmc(4) uses this.
Koshy