| 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
| ||
|
Message-ID: <20141106170323.GJ3592@console-pimps.org> 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/
Powered by blists - more mailing lists