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
| ||
|
Date: Mon, 12 Jun 2017 12:36:31 +0200 From: Jiri Olsa <jolsa@...hat.com> To: kan.liang@...el.com Cc: peterz@...radead.org, mingo@...hat.com, eranian@...gle.com, linux-kernel@...r.kernel.org, alexander.shishkin@...ux.intel.com, acme@...hat.com, torvalds@...ux-foundation.org, tglx@...utronix.de, vincent.weaver@...ne.edu, ak@...ux.intel.com Subject: Re: [PATCH V2 1/2] perf/x86/intel: enable CPU ref_cycles for GP counter On Fri, Jun 09, 2017 at 10:28:02AM -0700, kan.liang@...el.com 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
Powered by blists - more mailing lists