From: Thomas Gleixner <tglx@linutronix.de>
To: eranian@gmail.com
Cc: linux-kernel@vger.kernel.org, akpm@linux-foundation.org,
mingo@elte.hu, x86@kernel.org, andi@firstfloor.org,
sfr@canb.auug.org.au
Subject: Re: [patch 06/24] perfmon: generic x86 definitions (x86)
Date: Wed, 26 Nov 2008 17:15:46 +0100 (CET) [thread overview]
Message-ID: <alpine.LFD.2.00.0811261711130.3325@localhost.localdomain> (raw)
In-Reply-To: <7c86c4470811260750n4e6737c7h4518d89269f59ecb@mail.gmail.com>
Stephane,
On Wed, 26 Nov 2008, stephane eranian wrote:
> > 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.
If the interrupt detects that the context is dead, then it can disable
the counters and be done with it. And when the thread is switched in
again it just does not enable the counters when the context is dead.
> 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.
Well, this does not guarantee that no PMU interrupts happen before it
can process the TIF bit.
> >> 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.
Which is fine.
Thanks,
tglx
next prev parent reply other threads:[~2008-11-26 16:17 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-11-26 8:42 eranian
2008-11-26 11:20 ` Andi Kleen
2008-11-26 13:41 ` Thomas Gleixner
2008-11-26 14:19 ` stephane eranian
2008-11-26 15:44 ` Thomas Gleixner
2008-11-26 15:50 ` stephane eranian
2008-11-26 16:02 ` stephane eranian
2008-11-26 16:15 ` Thomas Gleixner [this message]
-- strict thread matches above, loose matches on Subject: below --
2008-11-25 21:36 eranian
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=alpine.LFD.2.00.0811261711130.3325@localhost.localdomain \
--to=tglx@linutronix.de \
--cc=akpm@linux-foundation.org \
--cc=andi@firstfloor.org \
--cc=eranian@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=sfr@canb.auug.org.au \
--cc=x86@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®