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

From: stephane eranian
Date: Wed Nov 26 2008 - 11:02:33 EST


Thomas,

On Wed, Nov 26, 2008 at 4:50 PM, stephane eranian
<eranian@xxxxxxxxxxxxxx> wrote:
>>> 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 ?
>>
>
> Well, there are possibly PMU interrupts. If the monitored thread is
> active on the CPU
> by the time the tool dies, then it will keep on running with
> monitoring on, until it is
> context switched out or dies.
>
> With the approach currently implemented, the TIF bit will be set and
> as soon as the thread
> leaves the kernel for any reason, it will execute the cleanup
> function which will stop
> monitoring and free the context.
>
To follow-up on that, worst case scenario is you get one more PMU interrupt.
The interrupt handler will notice the ZOMBIE state and will not reactivate
monitoring. The context will remain, but there will be no further cost to the
context switch because nothing will be saved or restored anymore.
--
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/