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, 7 Oct 2011 12:44:34 +0200
From:	Stephane Eranian <eranian@...gle.com>
To:	Peter Zijlstra <peterz@...radead.org>
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, Oct 7, 2011 at 12:32 PM, Peter Zijlstra <peterz@...radead.org> wrote:
> 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;
> };
>
Ok, I think I missed your original point about the anonymous
struct. What you're suggesting above is certainly fine with me.
I am not just used to bitfields mixed with other fields in a struct.
I'll fix that.
--
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/