linux-kernel - Re: [RFC] x86, perf: Add an aperfmperf driver

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]

Message-ID: <CALCETrU9R2z8vYMq+36H4E6inb_UVDgyQFywbfPN-=9Tu4Mqmw@mail.gmail.com>
Date:	Thu, 30 Apr 2015 15:09:34 -0700
From:	Andy Lutomirski <luto@...capital.net>
To:	Peter Zijlstra <peterz@...radead.org>
Cc:	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Len Brown <len.brown@...el.com>,
	Paul Mackerras <paulus@...ba.org>,
	Arnaldo Carvalho de Melo <acme@...nel.org>,
	Ingo Molnar <mingo@...hat.com>
Subject: Re: [RFC] x86, perf: Add an aperfmperf driver

On Thu, Apr 30, 2015 at 1:51 AM, Peter Zijlstra <peterz@...radead.org> wrote:
> On Wed, Apr 29, 2015 at 06:17:05PM -0700, Andy Lutomirski wrote:
>> >> > +     /* no sampling */
>> >> > +     if (event->hw.sample_period)
>> >> > +             return -EINVAL;
>> >>
>> >> You could have set pmu::capabilities =
>> >> PERF_PMU_CAP_NO_INTERRUPT which would also have killed that dead.
>> >
>> >
>> > That checks attr.sample_period.  I'm a bit confused about the
>> > relationship between event->hw and event->attr.  Do I not need to
>> > check hw.sample_period?
>
> event->attr is the perf_event_attr used to instantiate the event.
> event->hw is the hardware/working state of the event.
>
> You'll notice that attr::sample_period is part of a union and when
> !attr::freq will be used as the actual hw::sample_period. However when
> attr::freq we'll compute hw::sample_period based on actual event rates
> such that we'll approx attr::sample_freq.
>
> Setting pmu::capabilities = PERF_PMU_CAP_NO_INTERRUPT would be the best
> solution here.
>
>> > Before I submit v2, do you think this is actually worth doing?  I can
>> > see it being useful for answering questions like "did this workload
>> > end up running at full speed".
>> >
>>
>> To clarify, this is partially redundant with "cpu-cycles" and
>> "ref-cycles".  That being said, these are simpler, actually documented
>> as being appropriate for measuring cpu performance states, and don't
>> have any scheduling constraints.
>
> On the whole useful question; I dunno. It seems like something worth
> providing for the reasons you state. But I don't really get around to
> doing much userspace these days so I might not be the best to answer
> this.
>
> Also, you could extend this with IA32_PPERF (Skylake and later, see
> SDM-201501 book 3 section 14.4.5.1).

Interesting.  I can't test it for obvious reasons, and the enumeration
is not really straightforward, since it's non-architectural.  If I
send the patch, can you test?  Should the PMU still be called
aperfmperf?

>
>> Also, is perf stat able to count while idle?  perf stat -a -e
>> cpu-cycles sleep 1 reports very small numbers.
>
> Yes, perf stat -a (iow cpu events) should count while idle, note however
> that not all events count during halt, so its very much event dependent.

I see.  MPERF, etc only count in C0.

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