Message-ID: <7c86c4470811260750n4e6737c7h4518d89269f59ecb@mail.gmail.com>
Date:	Wed, 26 Nov 2008 16:50:17 +0100
From:	"stephane eranian" <eranian@...glemail.com>
To:	"Thomas Gleixner" <tglx@...utronix.de>
Cc:	linux-kernel@...r.kernel.org, akpm@...ux-foundation.org,
	mingo@...e.hu, x86@...nel.org, andi@...stfloor.org,
	sfr@...b.auug.org.au
Subject: Re: [patch 06/24] perfmon: generic x86 definitions (x86)

Thomas,

On Wed, Nov 26, 2008 at 4:44 PM, Thomas Gleixner <tglx@...utronix.de> wrote:
> 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 ?
>
Correct.

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

>> 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.
>
That's true except for the caveat described above.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists