[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1335280075.28150.202.camel@twins>
Date: Tue, 24 Apr 2012 17:07:55 +0200
From: Peter Zijlstra <peterz@...radead.org>
To: Juri Lelli <juri.lelli@...il.com>
Cc: tglx@...utronix.de, mingo@...hat.com, rostedt@...dmis.org,
cfriesen@...tel.com, oleg@...hat.com, fweisbec@...il.com,
darren@...art.com, johan.eker@...csson.com, p.faure@...tech.ch,
linux-kernel@...r.kernel.org, claudio@...dence.eu.com,
michael@...rulasolutions.com, fchecconi@...il.com,
tommaso.cucinotta@...up.it, nicola.manica@...i.unitn.it,
luca.abeni@...tn.it, dhaval.giani@...il.com, hgu1972@...il.com,
paulmck@...ux.vnet.ibm.com, raistlin@...ux.it,
insop.song@...csson.com, liming.wang@...driver.com
Subject: Re: [PATCH 10/16] sched: add resource limits for -deadline tasks.
On Fri, 2012-04-06 at 09:14 +0200, Juri Lelli wrote:
> From: Dario Faggioli <raistlin@...ux.it>
>
> Add resource limits for non-root tasks in using the SCHED_DEADLINE
> policy, very similarly to what already exists for RT policies.
>
> In fact, this patch:
> - adds the resource limit RLIMIT_DLDLINE, which is the minimum value
> a user task can use as its own deadline;
> - adds the resource limit RLIMIT_DLRTIME, which is the maximum value
> a user task can use as it own runtime.
>
> Notice that to exploit these, a modified version of the ulimit
> utility and a modified resource.h header file are needed. They
> both will be available on the website of the project.
>
> Signed-off-by: Dario Faggioli <raistlin@...ux.it>
> Signed-off-by: Juri Lelli <juri.lelli@...il.com>
I'm not sure this is the right way to go.. those existing things aren't
entirely as useful/sane as one might hope either.
The DLDLINE minimum is ok I guess, the DLRTIME one doesn't really do
anything, by spawning multiple tasks one can still saturate the cpu and
thus we have no effective control for unpriv users.
Ideally DLRTIME would be a utilization cap per user and tracked in
user_struct such that we can enforce a max utilization per user.
This also needs a global (and possibly per-cgroup) user limit too to cap
the total utilization of all users (excluding root) so that multiple
users cannot combine their efforts in order to bring down the machine.
In light of these latter controls the per-user control might be
considered optional, furthermore I don't particularly like the rlimit
infrastructure but I guess its the best we have for per-user like things
if indeed we want to go there.
--
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