Re: [patch 06/24] perfmon: generic x86 definitions (x86)

[Thomas Gleixner]

Stephane,

On Wed, 26 Nov 2008, stephane eranian wrote:
> The goal of the TIF flag is to force the thread to go do some extra work on
> kernel exit. There are two situations where this is necessary, there is one
> in the current patchset, the other is related to sampling (not yet provided).
> 
> With per-thread monitoring, a tool is monitoring another thread, possibly in
> another process. The monitored process and the tool may not be parent
> of each other.
> 
> What happens if the tool dies BEFORE it can cleanly close the
> monitoring session?
> 
> There are 2 scenarios:
>   1- the monitored process also had the perfmon file descriptor open,
> e.g., inherited
>      on fork/exec. In that case the monitored thread will keep on
> running to completion
>      with an attached perfmon context.

So no TIF work for this case, right ?
 
>   2- the monitoring had the last reference to the file descriptor. In
> that case, we have a
>      perfmon context attached to a thread but no mean to get to it
> from userland. This is
>      the case where we declare the context as ZOMBIE.
> 
>      I think Andi confused it with the meaning of ZOMBIE for the
> process. In this situation,
>      we want to cleanup the context and make sure monitoring is stopped.
>
>      That has to be done by the monitored thread. The issue is that
> the thread may notice
>      the context is ZOMBIE during context switch in. At this level, we
> run with interrupts
>      disabled, and it is not possible to free certain resources. So
> instead, we set the TIF
>      flag, and let the thread clean things up at a much higher level
> in the kernel execution
>      somewhere where we know we can safely call certain kernel APIs, e.g, kfree.

There is no harm, when the context is kept around, right ?
 
> Another possible solution (which is not implemented):
>      - just let the context attached and run the thread to completion.
> If another tool wants to
>        attach to the same thread, it will detect there is already a
> context attached, and that it is
>        marked ZOMBIE, so it will clean it up. This is a lazy cleanup approach.

Looks like ctx is a couple of hundred bytes, so just keep it around
until thread exit time or until the other tool does the cleanup
possibly by recycling the context.

Thanks,

	tglx

--
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/