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: <20141030124333.GA29540@htj.dyndns.org>
Date:	Thu, 30 Oct 2014 08:43:33 -0400
From:	Tejun Heo <tj@...nel.org>
To:	Peter Zijlstra <peterz@...radead.org>
Cc:	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>
Subject: Re: Cache Allocation Technology Design

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