On Fri, Jun 09, 2017 at 10:28:02AM -0700, [email protected] wrote:
SNIP
> + /*
> + * Correct the count number if applying ref_cycles replacement.
> + * There is a constant ratio between ref_cycles (event A) and
> + * ref_cycles replacement (event B). The delta result is from event B.
> + * To get accurate event A count, the real delta result must be
> + * multiplied with the constant ratio.
> + *
> + * It is handled differently for sampling and counting.
> + * - Fixed period Sampling: The period is already adjusted in
> + * scheduling for event B. The period_left is the remaining period
> + * for event B. Don't need to modify period_left.
> + * It's enough to only adjust event->count here.
> + *
> + * - Fixed freq Sampling: The adaptive frequency algorithm needs
> + * the last_period and event counts for event A to estimate the next
> + * period for event A. So the period_left is the remaining period
> + * for event A. It needs to multiply the result with the ratio.
> + * However, the period_left is also used to reload the event counter
> + * for event B in x86_perf_event_set_period. It has to be adjusted to
> + * event B's remaining period there.
> + *
> + * - Counting: It's enough to only adjust event->count for perf stat.
> + *
> + * - RDPMC: User can also read the counter directly by rdpmc/mmap.
> + * Users have to handle the adjustment themselves.
> + * For kernel, it only needs to guarantee that the offset is correct.
> + * In x86's arch_perf_update_userpage, the offset will be corrected
> + * if event B is used.
> + */
> + adjust_delta = delta;
> + if (hwc->flags & PERF_X86_EVENT_REF_CYCLES_REP) {
> + adjust_delta = delta * x86_pmu.ref_cycles_factor;
> +
> + if (is_sampling_event(event) && event->attr.freq)
> + local64_sub(adjust_delta, &hwc->period_left);
> + else
> + local64_sub(delta, &hwc->period_left);
shouldn't you use adjust_delta in here also ^^^ ?
jirka
