On 1/10/2018 5:22 AM, Jiri Olsa wrote:
On Mon, Jan 08, 2018 at 07:15:13AM -0800, kan.li...@intel.com wrote: SNIPThere is nothing need to do in x86_perf_event_set_period(). Because it is fixed period. The period_left is already adjusted. Signed-off-by: Kan Liang <kan.li...@linux.intel.com> --- arch/x86/events/intel/ds.c | 69 ++++++++++++++++++++++++++++++++++++++++++++-- 1 file changed, 67 insertions(+), 2 deletions(-) diff --git a/arch/x86/events/intel/ds.c b/arch/x86/events/intel/ds.c index 3674a4b..cc1f373 100644 --- a/arch/x86/events/intel/ds.c +++ b/arch/x86/events/intel/ds.c @@ -1251,17 +1251,82 @@ get_next_pebs_record_by_bit(void *base, void *top, int bit) return NULL; }+/*+ * Specific intel_pmu_save_and_restart() for auto-reload. + */ +static int intel_pmu_save_and_restart_reload(struct perf_event *event, + u64 reload_val, + int reload_times) +{ + struct hw_perf_event *hwc = &event->hw; + int shift = 64 - x86_pmu.cntval_bits; + u64 prev_raw_count, new_raw_count; + u64 delta; + + if ((reload_times == 0) || (reload_val == 0)) + return intel_pmu_save_and_restart(event);why is this check needed? AFAICS __intel_pmu_pebs_event is called only if reload_times != 0 and reload_val is always non zero for sampling
Here is a sanity check for reload_times and reload_val. Right, usually they are non zero. I think it should not bring any issues. Right? If so, I think we may still keep it? Thanks, Kan
