linux-kernel - Re: [patch 02/24] perfmon: base code

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <alpine.LFD.2.00.0811272157370.3325@localhost.localdomain>
Date:	Thu, 27 Nov 2008 21:59:19 +0100 (CET)
From:	Thomas Gleixner <tglx@...utronix.de>
To:	eranian@...il.com
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 02/24] perfmon: base code

On Thu, 27 Nov 2008, stephane eranian wrote:

> On Thu, Nov 27, 2008 at 8:35 PM, Thomas Gleixner <tglx@...utronix.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

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