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: <20150430085122.GV5029@twins.programming.kicks-ass.net>
Date:	Thu, 30 Apr 2015 10:51:22 +0200
From:	Peter Zijlstra <peterz@...radead.org>
To:	Andy Lutomirski <luto@...capital.net>
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 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).

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