Re: [PATCH 01/12] perf_events: add generic taken branch samplingsupport

[Peter Zijlstra]

On Fri, 2011-10-07 at 12:28 +0200, Stephane Eranian wrote:
> On Thu, Oct 6, 2011 at 6:57 PM, Peter Zijlstra <peterz@xxxxxxxxxxxxx> 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@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/