Messages in this thread | | | Date | Wed, 26 Nov 2008 16:44:05 +0100 (CET) | From | Thomas Gleixner <> | Subject | Re: [patch 06/24] perfmon: generic x86 definitions (x86) |
| |
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
| |