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 02/24] perfmon: base code
Date: Thu, 27 Nov 2008 21:59:19 +0100 (CET) [thread overview]
Message-ID: <alpine.LFD.2.00.0811272157370.3325@localhost.localdomain> (raw)
In-Reply-To: <7c86c4470811271149m5f5556c0y468be509bb6a200@mail.gmail.com>
On Thu, 27 Nov 2008, stephane eranian wrote:
> On Thu, Nov 27, 2008 at 8:35 PM, Thomas Gleixner <tglx@linutronix.de> wrote:
> > Stephane,
> >
> > On Thu, 27 Nov 2008, stephane eranian wrote:
> >
> >> >> session is independent of each other. You can therefore measure different
> >> >> things on different CPUs. Reservation is thus done independently for each
> >> >> CPU, therefore we need a cpu bitmask to track allocation.
> >> >
> >> > Ok. Question: if you do a one CPU wide session with perfom, can you
> >> > still do thread monitoring on the same CPU ?
> >> >
> >> No. They are currently mutually exclusive.
> >>
> >> > If no, what prevents that a monitored thread is migrated to such a CPU ?
> >> >
> >> Nothing. AND you don't want to change affinity because you are monitoring.
> >> So the current restriction is that cpu-wide and per-thread are
> >> mutually exclusive.
> >
> > And how is this achieved ? Currently there seems nothing which
> > prevents a per-thread vs. cpu-wide monitoring.
> >
> That's true, but that's because cpu-wide support is not included in the
> patchset.
That's the whole point I'm making. For the current patch set the
simple global vs. thread exclusivity is sufficient and correct.
When we gradually add stuff then we simply can add the extra checks
and think about the impact and consequences in that context.
Thanks,
tglx
next prev parent reply other threads:[~2008-11-27 21:00 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-11-26 8:42 eranian
2008-11-26 11:17 ` Andi Kleen
2008-11-27 11:23 ` Thomas Gleixner
2008-11-27 17:24 ` Thomas Gleixner
2008-11-27 17:47 ` stephane eranian
2008-11-27 18:28 ` Thomas Gleixner
2008-11-27 18:41 ` Andi Kleen
2008-11-27 18:36 ` Thomas Gleixner
2008-11-27 18:54 ` stephane eranian
2008-11-27 18:51 ` stephane eranian
2008-11-27 19:35 ` Thomas Gleixner
2008-11-27 19:49 ` stephane eranian
2008-11-27 20:59 ` Thomas Gleixner [this message]
-- strict thread matches above, loose matches on Subject: below --
2008-11-25 21:35 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.0811272157370.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®