[PATCH][2.6.8-rc1-mm1] perfctr inheritance 0/3: summary

From: Mikael Pettersson
Date: Fri Jul 16 2004 - 20:56:22 EST


This set of patches add "inheritance" support to the per-process
performance counters code in 2.6.8-rc1-mm1, bringing it in sync
with the stand-alone perfctr-2.7.4 package.

Inheritance has the following semantics:
- At fork()/clone(), the child gets the same perfctr control
settings (but fresh/reset counters) as its parent.
- As an exited child is reaped, if it still uses the exact
same control as its parent, then its final counts (self plus
children) are merged into its parent's "children counts" state.
This is analogous to how the kernel handles plain time etc.
If either parent or child has reprogrammed their counters since
the fork(), then the child's final counts are not merged back.

This feature is one users have asked for repeatedly, and it's
the only embarrasing feature omission in the current code. It's
not perfect, since one cannot distinguish child 1 from child 2
or some grandchild, but it's easy and cheap to implement.

The implementation is as follows:
- The per-process counters object is extended with "children counts".
- To determine if the control in parent and child are related, each
new control setting gets a new 64-bit id. fork() copies control and
id to the child. release_task() checks the ids of child and parent
and only merges the final counts if the ids match.
- The copy_task() callback is renamed to copy_thread(), and also
takes the "struct pt_regs *regs" as parameter. "regs" is needed to
check if the thread is created for a user-space fork()/clone(), or
a kernel-level thread; in the latter case the perfctr state is
_not_ inherited.
- Adds callback to release_task(), invoked at the point where the
other child time etc values are propagated to the parent.
- The tsk->thread.perfctr locking rules are strengthened to always
take task_lock(tsk). Previously it sufficed to disable preemption
when HT P4s couldn't occur.

The updated perfctr-2.7.4 library and tools package is needed to
actually use the updated kernel code.

Three patches follow:
1/3: updates to the driver
2/3: updates to the kernel callbacks
3/3: updates to the documentation

Signed-off-by: Mikael Pettersson <mikpe@xxxxxxxxx>
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/