From: Mikael Pettersson - Documentation changes for new task event callbacks, updated locking rules, API update, and TODO list update Signed-off-by: Mikael Pettersson Signed-off-by: Andrew Morton --- 25-akpm/Documentation/perfctr/virtual.txt | 37 +++++++++++++++++------------- 1 files changed, 22 insertions(+), 15 deletions(-) diff -puN Documentation/perfctr/virtual.txt~perfctr-inheritance-3-3-documentation-updates Documentation/perfctr/virtual.txt --- 25/Documentation/perfctr/virtual.txt~perfctr-inheritance-3-3-documentation-updates 2004-07-26 15:51:11.501638144 -0700 +++ 25-akpm/Documentation/perfctr/virtual.txt 2004-07-26 15:51:11.505637536 -0700 @@ -67,12 +67,17 @@ Thread Management Hooks Virtual perfctrs hooks into several thread management events: - exit_thread(): Calls perfctr_exit_thread() to stop the counters - and detach the thread's vperfctr object. + and mark the vperfctr object as dead. - copy_thread(): Calls perfctr_copy_thread() to initialise - the child's vperfctr pointer. Currently the settings are - not inherited from parent to child, so the pointer is set - to NULL in the child's thread_struct. + the child's vperfctr pointer. The child gets a new vperfctr + object containing the same control data as its parent. + Kernel-generated threads do not inherit any vperfctr state. + +- release_task(): Calls perfctr_release_task() to detach the + vperfctr object from the thread. If the child and its parent + still have the same perfctr control settings, then the child's + final counts are propagated back into its parent. - switch_to(): * Calls perfctr_suspend_thread() on the previous thread, to @@ -109,7 +114,7 @@ CONFIG_PERFCTR_VIRTUAL is disabled. Synchronisation Rules --------------------- -There are four types of accesses to a thread's perfctr state: +There are five types of accesses to a thread's perfctr state: 1. Thread management events (see above) done by the thread itself. Suspend, resume, and sample are lock-less. @@ -134,10 +139,14 @@ There are four types of accesses to a th (creat, unlink, exit) perform a task_lock() on the owner thread before accessing the perfctr pointer. - When concurrent set_cpus_allowed() isn't a problem (because the - architecture doesn't have a notion of forbidden CPUs), atomicity - of updates to the thread's perfctr pointer is ensured by disabling - preemption. +5. release_task(). + While reaping a child, the kernel only takes the tasklist_lock to + prevent the parent from changing or disappearing. This does not + prevent the parent's perfctr state pointer from changing. Concurrent + accesses to the parent's "children counts" state are also possible. + + To avoid these issues, perfctr_release_task() performs a task_lock() + on the parent. The Pseudo File System ---------------------- @@ -253,14 +262,16 @@ thread that is stopped and under ptrace Reading the State ----------------- int err = sys_vperfctr_read(int fd, struct perfctr_sum_ctrs *sum, - struct vperfctr_control *control); + struct vperfctr_control *control, + struct perfctr_sum_ctrs *children); 'fd' must be the return value from a call to sys_vperfctr_open(). This operation copies data from the perfctr state object to user-space. If 'sum' is non-NULL, then the counter sums are written to it. If 'control' is non-NULL, then the control data -is written to it. +is written to it. If 'children' is non-NULL, then the sums of +exited childrens' counters are written to it. If the perfctr state object is attached to the current thread, then the counters are sampled and updated first. @@ -346,10 +357,5 @@ Notes: Limitations / TODO List ======================= -- Perfctr settings are not inherited from parent to child at fork(). - The issue is not fork() but propagating final counts from children - to parents, and allowing user-space to distinguish "self" counts - from "children" counts. - An implementation of this feature is being planned. - Buffering of overflow samples is not implemented. So far, not a single user has requested it. _