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

[stephane eranian]

Thomas,

On Wed, Nov 26, 2008 at 2:41 PM, Thomas Gleixner <tglx@xxxxxxxxxxxxx> wrote:
> On Wed, 26 Nov 2008, eranian@xxxxxxxxxxxxxx wrote:
>
>> This patch adds definitions for the perfmon interrupt vector
>> and thread info flags. It is common to i386 and x86_64 code.
>
>> +#define TIF_PERFMON_WORK     9       /* work for pfm_handle_work() */
>
> I can see the requirement for an apic vector, but why do you need a
> TIF flag ?
>
Ok, this is a good question, so let me explain.

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.

  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.

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