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: <20150109125829.GF29390@twins.programming.kicks-ass.net>
Date:	Fri, 9 Jan 2015 13:58:29 +0100
From:	Peter Zijlstra <peterz@...radead.org>
To:	Matt Fleming <matt@...sole-pimps.org>
Cc:	Ingo Molnar <mingo@...nel.org>, Jiri Olsa <jolsa@...hat.com>,
	Arnaldo Carvalho de Melo <acme@...nel.org>,
	Andi Kleen <andi@...stfloor.org>,
	Thomas Gleixner <tglx@...utronix.de>,
	linux-kernel@...r.kernel.org, "H. Peter Anvin" <hpa@...or.com>,
	Kanaka Juvva <kanaka.d.juvva@...el.com>,
	Matt Fleming <matt.fleming@...el.com>
Subject: Re: [PATCH v4 10/11] perf/x86/intel: Perform rotation on Intel CQM
 RMIDs

On Fri, Jan 09, 2015 at 12:55:07PM +0000, Matt Fleming wrote:
> On Wed, 07 Jan, at 01:16:17PM, Peter Zijlstra wrote:
> > On Fri, Nov 14, 2014 at 09:15:11PM +0000, Matt Fleming wrote:
> >  +	/*
> > > +	 * A reasonable upper limit on the max threshold is the number
> > > +	 * of lines tagged per RMID if all RMIDs have the same number of
> > > +	 * lines tagged in the LLC.
> > > +	 *
> > > +	 * For a 35MB LLC and 56 RMIDs, this is ~1.8% of the LLC.
> > > +	 */
> > > +	__intel_cqm_max_threshold =
> > > +		boot_cpu_data.x86_cache_size * 1024 / (cqm_max_rmid + 1);
> > 
> > Seeing how a percentage is without unit, the 35MB figure seems
> > pointless.
>  
> It's only an example to demonstrate that this fudge calculation makes
> sense on the current class of CQM-enabled hardware.
> 
> > Also, why would a flat distribution be a good measure for 'empty'? I
> > would think that would in fact constitute in use.
>  
> It's not, it's a good measure for 'full'. This is the *max* threshold.
> When searching for RMIDs to stabilize we'll stop searching if
> __intel_cqm_threshold == __intel_cqm_max_threshold, since that indicates
> all our RMIDs have *so* many lines tagged that it's unlikely increasing
> __intel_cqm_threshold any further would be a win.

Right, but we'll also consider RMIDs with less than this as fit for
reuse. So we'll re-use RMIDs that are effectively full.

Our aim is to acquire an 'empty' RMID, not give up and start reusing
full ones just because, right?
--
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