linux-kernel - RE: [PATCH V2 1/2] perf/x86/intel: enable CPU ref

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

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <37D7C6CF3E00A74B8858931C1DB2F0775370B837@SHSMSX103.ccr.corp.intel.com>
Date:   Mon, 12 Jun 2017 13:07:35 +0000
From:   "Liang, Kan" <kan.liang@...el.com>
To:     Jiri Olsa <jolsa@...hat.com>
CC:     "peterz@...radead.org" <peterz@...radead.org>,
        "mingo@...hat.com" <mingo@...hat.com>,
        "eranian@...gle.com" <eranian@...gle.com>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "alexander.shishkin@...ux.intel.com" 
        <alexander.shishkin@...ux.intel.com>,
        "acme@...hat.com" <acme@...hat.com>,
        "torvalds@...ux-foundation.org" <torvalds@...ux-foundation.org>,
        "tglx@...utronix.de" <tglx@...utronix.de>,
        "vincent.weaver@...ne.edu" <vincent.weaver@...ne.edu>,
        "ak@...ux.intel.com" <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 ^^^ ?

No, we shouldn't use adjust_delta for all cases. Only fixed freq sampling is
enough.

For fixed period sampling, we already adjust the period in scheduling.
So the period_left here is already adjusted. We should not do it twice.
For RDPMC, user will handle the adjustment. The kernel should not do
any changes here.
For counting (perf stat), it doesn't matter. We only care about the
event->count.
   
Thanks,
Kan