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]
Date:	Fri, 17 Apr 2015 14:19:58 +0000
From:	"Liang, Kan" <kan.liang@...el.com>
To:	Peter Zijlstra <peterz@...radead.org>
CC:	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"mingo@...nel.org" <mingo@...nel.org>,
	"acme@...radead.org" <acme@...radead.org>,
	"eranian@...gle.com" <eranian@...gle.com>,
	"andi@...stfloor.org" <andi@...stfloor.org>
Subject: RE: [PATCH V6 4/6] perf, x86: handle multiple records in PEBS buffer



> -----Original Message-----
> From: Peter Zijlstra [mailto:peterz@...radead.org]
> Sent: Friday, April 17, 2015 9:13 AM
> To: Liang, Kan
> Cc: linux-kernel@...r.kernel.org; mingo@...nel.org;
> acme@...radead.org; eranian@...gle.com; andi@...stfloor.org
> Subject: Re: [PATCH V6 4/6] perf, x86: handle multiple records in PEBS
> buffer
> 
> On Fri, Apr 17, 2015 at 12:50:33PM +0000, Liang, Kan wrote:
> >
> >
> > > >
> > > >  A) the CTRn value reaches 0:
> > > >     - the corresponding bit in GLOBAL_STATUS gets set
> > > >     - we start arming the hardware assist
> > > >
> > > >     < some unspecified amount of time later --
> > > >         this could cover multiple events of interest >
> > > >
> > > >  B) the hardware assist is armed, any next event will trigger it
> > > >
> > > >  C) a matching event happens:
> > > >     - the hardware assist triggers and generates a PEBS record
> > > >       this includes a copy of GLOBAL_STATUS at this moment
> > > >     - if we auto-reload we (re)set CTRn
> > >
> > > Is this actually true? Do we reload here or on A ?
> > >
> >
> > Yes, on C.
> > According to SDM Volume 3, 18.7.1.1, the reset value will be loaded
> > after each PEBS record is written, which is done by hw assist.
> 
> OK, then I did indeed remember that right.
> 
> But that brings us to patch 1 of this series, how is that correct in the face of
> this? There is an arbitrary delay (A->B) added to the period.
> And the Changelog of course never did bother to make that clear.

OK. I will update the changelog for patch 1 as below.
---
When a fixed period is specified, this patch make perf use the PEBS
auto reload mechanism. This makes normal profiling faster, because
it avoids one costly MSR write in the PMI handler.
However, the reset value will be loaded by hardware assist. There is 
a little bit delay compared to previous non-auto-reload mechanism.
The delay is arbitrary but very small.

Thanks,
Kan


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ