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:	Thu, 30 Jul 2015 18:24:52 +0300
From:	Alexander Shishkin <alexander.shishkin@...ux.intel.com>
To:	Peter Zijlstra <a.p.zijlstra@...llo.nl>
Cc:	Ingo Molnar <mingo@...hat.com>, linux-kernel@...r.kernel.org,
	adrian.hunter@...el.com, x86@...nel.org, hpa@...or.com,
	acme@...radead.org
Subject: Re: [PATCH v1] perf/x86/intel/pt: Do not force sync packets on every schedule-in

Alexander Shishkin <alexander.shishkin@...ux.intel.com> writes:

> Currently, the PT driver zeroes out the status register every time before
> starting the event. However, all the writable bits are already taken care
> of in pt_handle_status() function, except the new PacketByteCnt field,
> which in new versions of PT contains the number of packet bytes written
> since the last sync (PSB) packet. Zeroing it out before enabling PT forces
> a sync packet to be written. This means that, with the existing code, a
> sync packet (PSB and PSBEND, 18 bytes in total) will be generated every
> time a PT event is scheduled in.
>
> To avoid these unnecessary syncs and save a WRMSR in the fast path, this
> patch changes the default behavior to not clear PacketByteCnt field, so
> that the sync packets will be generated with the period specified as
> "psb_period" attribute config field. This has little impact on the trace
> data as the other packets that are normally sent within PSB+ (between PSB
> and PSBEND) have their own generation scenarios which do not depend on the
> sync packets.
>
> One exception where we do need to force PSB like this when tracing starts,
> so that the decoder has a clear sync point in the trace. For this purpose
> we aready have hw::itrace_started flag, which we are currently using to
> output PERF_RECORD_ITRACE_START. This patch moves setting itrace_started
> from perf core to the pmu::start, where it should still be 0 on the very
> first run.
>
> Signed-off-by: Alexander Shishkin <alexander.shishkin@...ux.intel.com>
>
> perf/x86/intel/pt: fixup with no force psb
>
> Signed-off-by: Alexander Shishkin <alexander.shishkin@...ux.intel.com>

Argh, it is not my day today.

Regards,
--
Alex
--
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