linux-kernel - Re: [PATCH 2/3] perf/x86/intel/pt: Add an option to not force PSB+ on every schedule-in

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 14:53:51 +0300
From:	Alexander Shishkin <alexander.shishkin@...ux.intel.com>
To:	Peter Zijlstra <peterz@...radead.org>
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 2/3] perf/x86/intel/pt: Add an option to not force PSB+ on every schedule-in

Peter Zijlstra <peterz@...radead.org> writes:

> On Fri, Jul 17, 2015 at 04:34:09PM +0300, Alexander Shishkin wrote:
>> 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 adds a new attribute config bit "no_force_psb", which will disable
>> this zeroing WRMSR.
>
> Why is this exposed?

The default behavior, which we have in the kernel now, is to always
force the PSB, so if we change it, we need to make sure nobody is
relying on it being the default behavior. Granted, for the hardware
that's on the market right now it won't make a difference (it generates
PSB+ at least every 256 bytes anyway), but in future if we change the
default, newer hardware will produce different results with 4.2 than with
the newer kernels and this would be a tad sloppy.

The tools, however, can decide to set no_force_psb=1 when no_force_psb
is available (sysfs caps) and otherwise the default behavior will be the
same as no_force_psb==0. Makes sense?

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/