Messages in this thread | | | Subject | RE: [patch] x86, perf_counter, bts: add bts to perf_counter | From | Peter Zijlstra <> | Date | Fri, 07 Aug 2009 15:05:58 +0200 |
| |
On Fri, 2009-08-07 at 13:18 +0100, Metzger, Markus T wrote:
> >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. > > > OK, that makes sense. > > So I'll still check for sample_period=1 but when I fail to acquire BTS, I don't > fall back to the generic counter and return an error instead. > > Is that it?
Yeah, something like that, simply return -EBUSY/-EAGAIN or so.
However I'd look into adding something to intel_pmu_init() which would set intel_bts_available to 1 when the CPU should support BTS, that'll ease the reserve_bts_hardware() error case and help with allowing this fallback as well.
| |