On Mon, Jan 05, 2015 at 03:57:39PM +0100, Peter Zijlstra wrote: > On Fri, Nov 21, 2014 at 04:24:26PM +0000, Daniel Thompson wrote: > > diff --git a/arch/arm/kernel/perf_event.c b/arch/arm/kernel/perf_event.c > > index 266cba46db3e..ab68833c1e31 100644 > > --- a/arch/arm/kernel/perf_event.c > > +++ b/arch/arm/kernel/perf_event.c > > @@ -115,8 +115,14 @@ int armpmu_event_set_period(struct perf_event *event) > > ret = 1; > > } > > > > - if (left > (s64)armpmu->max_period) > > - left = armpmu->max_period; > > + /* > > + * Limit the maximum period to prevent the counter value > > + * from overtaking the one we are about to program. In > > + * effect we are reducing max_period to account for > > + * interrupt latency (and we are being very conservative). > > + */ > > + if (left > (armpmu->max_period >> 1)) > > + left = armpmu->max_period >> 1; > > On x86 we simply half max_period, why did you choose to do differently?
In truth because I didn't look at the x86 code... there is an existing halving of max_period in the arm code and that was enough to satisfy me that halving max_period was reasonable. Predividing max_period looks to me like it would work for ARM too although I don't think we could blame hardware insanity for doing so ;-). Will: Do you want me to update this? -- Daniel Thompson (STMicroelectronics) <[email protected]> 1000 Aztec West, Almondsbury, Bristol, BS32 4SQ. 01454 462659 If a car is a horseless carriage then is a motorcycle a horseless horse? -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
