linux-kernel - RE: [patch] x86, perf_counter, bts: add bts to perf

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 Aug 2009 12:29:09 +0200
From:	Peter Zijlstra <a.p.zijlstra@...llo.nl>
To:	"Metzger, Markus T" <markus.t.metzger@...el.com>
Cc:	Ingo Molnar <mingo@...e.hu>,
	"tglx@...utronix.de" <tglx@...utronix.de>,
	"hpa@...or.com" <hpa@...or.com>,
	"markus.t.metzger@...il.com" <markus.t.metzger@...il.com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: RE: [patch] x86, perf_counter, bts: add bts to perf_counter

On Fri, 2009-08-07 at 11:18 +0100, Metzger, Markus T wrote:
> >-----Original Message-----
> >From: Peter Zijlstra [mailto:a.p.zijlstra@...llo.nl]
> >Sent: Friday, August 07, 2009 10:21 AM
> >To: Metzger, Markus T
> >Cc: Ingo Molnar; tglx@...utronix.de; hpa@...or.com; markus.t.metzger@...il..com; linux-
> >kernel@...r.kernel.org
> >Subject: RE: [patch] x86, perf_counter, bts: add bts to perf_counter
> >
> >On Fri, 2009-08-07 at 08:29 +0100, Metzger, Markus T wrote:
> >
> >> I incorporated Peter's review comments, except that I would not enforce sample_period == 1
> >> when branch tracing is requested. There might be users who want to sample the IP every 100.000'th
> >> branch for profiling reasons.
> >
> >But in case you don't set sample_period==1 then you won't be able to
> >match the BTS counter:
> >
> >+       if (unlikely((event ==
> >+                     x86_pmu.event_map(PERF_COUNT_HW_BRANCH_INSTRUCTIONS)) &&
> >+                    (hwc->sample_period == 1)))
> >+               return X86_PMC_IDX_FIXED_BTS;
> >
> >Also,
> >
> >+               /*
> >+                * Try to use BTS for branch tracing. If that is not
> >+                * available, try to get a generic counter.
> >+                */
> >+               if (unlikely(!cpuc->ds))
> >+                       goto try_generic;
> >
> >How will be use a generic counter for BTS, will it generate an NMI for
> >every encountered branch? That might very will hit the throttle as that
> >might be many.
> >
> >Would it not be better to force sample_period==1 usage onto the BTS and
> >simply fail if its not available?
> 
> In case someone requests a bigger sample-period, we would use the normal counter - as we
> do without this patch.
> We would also use the normal counter in case BTS is not available.
> 
> In that case, we won't have BTS, we will have normal performance monitoring.
> It will be throttled just like any other sampling request with small sample_period.
> 
> If we forced sample_period = 1 for PERF_COUNT_HW_BRANCH_INSTRUCTIONS, we would remove
> functionality.

Right, what I'm worried about though is the BTS overload scenario.
Normally when we'd create more counters than we'd have hardware for we'd
simply time share the stuff.

However BTS now has a second class fallback for period==1 which
complicates all this because it will likely not generate consistent
results.

So I was thinking that _if_ the hardware supports BTS we'd not do the
fallback to generic bits if event == HW_BRANCH_INST && period == 1.

I agree on the period > 1 using the generic counters.

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