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]

Message-ID: <alpine.DEB.2.10.1410301610000.27874@vshiva-Udesk>
Date:	Thu, 30 Oct 2014 16:18:33 -0700 (PDT)
From:	Vikas Shivappa <vikas.shivappa@...el.com>
To:	Tejun Heo <tj@...nel.org>
cc:	Peter Zijlstra <peterz@...radead.org>,
	Vikas Shivappa <vikas.shivappa@...el.com>,
	"Auld, Will" <will.auld@...el.com>,
	Matt Fleming <matt@...sole-pimps.org>,
	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 Thu, 30 Oct 2014, Tejun Heo wrote:

> Hello, Peter.
>
> On Thu, Oct 30, 2014 at 08:07:25AM +0100, Peter Zijlstra wrote:
>> If this means echo $tid > tasks, then sorry we can't do. There is a
>> limited number of hardware resources backing this thing. At some point
>> they're consumed and something must give.
>
> And that something shouldn't be disallowing task migration across
> cgroups.  This simply doesn't work with co-mounting or unified
> hierarchy.  cpuset automatically takes on the nearest ancestor's
> configuration which has enough execution resources.  Maybe that can be
> an option for this too?


One way to it is to merge the CAT cgroups into the cpuset . In essense 
there is no CAT cgroup seperately and we just have a new file 'cbm' in the 
cpuset. This would be visible only when system has Cache allocation 
support and the user can manipulate the cache bit mask here.
The  user can use the already existing cpu_exclusive file in the cpuset 
to mark the cgroups to use exclusive CPUs.
That way we simplify and reuse cpuset code/hierarchy .. ?

Thanks,
Vikas



>
> One of the problems is that we generally assume that a task can run
> some point in time in a lot of places in the kernel and can't just not
> run a task indefinitely because it's in a cgroup configured certain
> way.
>
>> So either we fail mkdir, but that means allocating CLOS IDs for possibly
>> empty cgroups, or we allocate on demand which means failing task
>> assignment.
>
> Can't fail mkdir or css enabling either.  Again, co-mounting and
> unified hierarchy.  Also, the behavior is just horrible to use from
> userland.
>
>> The same -- albeit for a different reason -- is true of the RT sched
>> groups, we simply cannot instantiate them such that tasks can join,
>> sysads _have_ to configure them before we can add tasks to them.
>
> Yeah, RT is one of the main items which is problematic, more so
> because it's currently coupled with the normal sched controller and
> the default config doesn't have any RT slice.  Do we completely block
> RT task w/o slice?  Is that okay?
>
> Thanks.
>
> -- 
> tejun
>
--
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/