linux-kernel - Re: Cache Allocation Technology Design

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, 6 Nov 2014 17:03:23 +0000
From:	Matt Fleming <matt@...sole-pimps.org>
To:	Peter Zijlstra <peterz@...radead.org>
Cc:	Vikas Shivappa <vikas.shivappa@...el.com>,
	Tejun Heo <tj@...nel.org>, "Auld, Will" <will.auld@...el.com>,
	Vikas Shivappa <vikas.shivappa@...ux.intel.com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"Fleming, Matt" <matt.fleming@...el.com>, h.peter.anvin@...el.com
Subject: Re: Cache Allocation Technology Design

On Tue, 04 Nov, at 02:17:14PM, Peter Zijlstra wrote:
> 
> I don't like extending cpusets further. Its already a weird and too big
> controller.
> 
> What is wrong with having a specific CQM controller and using it
> together with cpusets where desired?

The specific problem that conflating cpusets and the CAT controller is
trying to solve is that on some platforms the CLOS ID doesn't move with
data that travels up the cache hierarchy, i.e. we lose the CLOS ID when
data moves from LLC to L2.

I think the idea with pinning CLOS IDs to a specific cpu and any tasks
that are using that ID is that it works around this problem out of the
box, rather than requiring sysadmins to configure things.

-- 
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/