Re: [perfmon2] when is child task released from kernel memory?

[Andrej v. d. Z. <and...@gm...>]

Hi,

Thanks for your answers, it is getting clearer.

Maybe I am misunderstanding the second waitpid() that waits for the
child to exit. I thought of this as something like a rendez-vous where
the childs execution is halted temporarily. But I understand now that
the attaching process only receives a signal, and the child runs away
immediately after it delivers the signal? And that the counters are
owned in the context belonging to the attaching process, so it remains
available until it closes the file descriptor?

Thank you,
Andrej


On Tue, Nov 25, 2008 at 6:05 PM, stephane eranian
<er...@go...> wrote:
> Hi,
>
> On Tue, Nov 25, 2008 at 6:35 AM, Andrej van der Zee
> <and...@gm...> wrote:
>> Hi,
>>
>> Probably a very basic question, but unfortunately not for me: When a
>> parent process attaches to a forked child it finally can access the
>> pfm-context after the parent is finished waiting for the child to
>> exit. At this point, is the child task still in kernel memory?  And if
>> so, at which point does the kernel know it can release it?
>>
> I think your question is orthogonal to perfmon2. What happens between
> a child and its parent is not modified in anyway by perfmon2.
>
> You need to have the thread stopped when you attach a perfmon2 context.
> This is accomplished today via ptrace (PTRACE_ATTACH). Then, you can
> detach the thread and let it run to completion. Should you need to read out
> some counts before it dies, you'd have to stop the thread again via ptrace.
> When the thread eventually terminates, monitoring stops and the context is
> automatically detached. Death of a process is a two-step process, there is
> a signal (SIGCHLD) and then you need to reclaim the remaining resources
> via wait().
>
> A key point to understand is that a thread can never reclaim all of
> its  resources,
> this is always accomplished by the thread calling wait(), could be the parent
> or the init process. As for the perfmon2 context, it remains available after
> the signal and after the wait. The reason for this and this is a key design
> choice, is that the "owner" of the perfmon2 context is not the monitored
> thread, it is whichever process has a file descriptor open on it. Now you
> see why the perfmon2 context can survive the death of the monitored
> thread (except for self-monitoring, of course).
>
> If your question was more along the lines of: can I peek at the child's memory
> when I get the SIGCHLD? I think the answer is no because the memory
> resource has already been freed by then (do_exit).
>



-- 
Andrej van der Zee
2-40-19 Koenji-minami
Suginami-ku, Tokyo
166-0003 JAPAN
Mobile: +81-(0)80-65251092
Phone/Fax: +81-(0)3-3318-3155