linux-kernel - Re: [PATCH v3 10/11] perf/x86/intel: Perform rotation on Intel CQM RMIDs

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:	Mon, 10 Nov 2014 20:56:53 +0000
From:	Matt Fleming <matt@...sole-pimps.org>
To:	Peter Zijlstra <peterz@...radead.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 v3 10/11] perf/x86/intel: Perform rotation on Intel CQM
 RMIDs

On Fri, 07 Nov, at 01:20:52PM, Peter Zijlstra wrote:
> On Thu, Nov 06, 2014 at 12:23:21PM +0000, Matt Fleming wrote:
> > +/*
> > + * If we fail to assign a new RMID for intel_cqm_rotation_rmid because
> > + * cachelines are still tagged with RMIDs in limbo, we progressively
> > + * increment the threshold until we find an RMID in limbo with <=
> > + * __intel_cqm_threshold lines tagged. This is designed to mitigate the
> > + * problem where cachelines tagged with an RMID are not steadily being
> > + * evicted.
> > + *
> > + * On successful rotations we decrease the threshold back towards zero.
> > + *
> > + * __intel_cqm_max_threshold provides an upper bound on the threshold,
> > + * and is measured in bytes because it's exposed to userland.
> > + */
> > +static unsigned int __intel_cqm_threshold;
> > +static unsigned int __intel_cqm_max_threshold = -1;
> 
> Should we initialize that to a finite value? Surely results are absolute
> crap if we do indeed reach that max?

I don't think we'll ever reach that max, it'll bottom out once it
reaches the size of the LLC, since the pathological case is that the
RMID you're currently trying to stabilize is used to tag every line in
the LLC.

Not sure what a reasonable finite value would be here though? 10% of the
LLC size?

-- 
Matt Fleming, Intel Open Source Technology Center
--
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/