linux-kernel - Re: [PATCH 01/12] perf_events: add generic taken branch sampling support

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] [thread-next>] [day] [month] [year] [list]

Date:	Fri, 07 Oct 2011 12:32:13 +0200
From:	Peter Zijlstra <peterz@...radead.org>
To:	Stephane Eranian <eranian@...gle.com>
Cc:	linux-kernel@...r.kernel.org, mingo@...e.hu, acme@...hat.com,
	ming.m.lin@...el.com, andi@...stfloor.org, robert.richter@....com,
	ravitillo@....gov
Subject: Re: [PATCH 01/12] perf_events: add generic taken branch sampling
 support

On Fri, 2011-10-07 at 12:28 +0200, Stephane Eranian wrote:
> On Thu, Oct 6, 2011 at 6:57 PM, Peter Zijlstra <peterz@...radead.org> wrote:
> > On Thu, 2011-10-06 at 16:49 +0200, Stephane Eranian wrote:
> >>  struct perf_branch_entry {
> >>         __u64                           from;
> >>         __u64                           to;
> >> +       struct {
> >> +               __u64                   mispred:1,  /* target mispredicted */
> >> +                                       predicted:1,/* target predicted */
> >> +                                       reserved:62;
> >> +       };
> >>  };
> >
> > Why that anonymous structure?
> >
> The interface can return more than source/destination, it can also
> return prediction infos.
> Prediction is boolean, thus we only need a couple of bits. The reason
> there are two bits
> and not just one is to disambiguate between: predicted correctly and
> 'prediction reporting
> unsupported'. For instance, prediction is also supported since
> Nehalem, Core2/Atom do
> not have it.

Right, I got that.

> But maybe you're just commenting of the anonymous vs. named struct for
> that?

I don't see the need for any struct, why can't the bitfield live in
perf_branch_entry proper?

> It is just for convenience. Isn't that the same argument for the
> anonymous bitfield
> in struct perf_event_attr? 

But that isn't wrapped in a structure either is it..

I guess I'm asking, what's wrong with:

struct perf_branch_entry {
	__u64		from;
	__u64		to;
	__u64		mispred:1,
			predicted:1,
			reserved:62;
};

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