Message-ID: <4FC34011.4040505@gmail.com>
Date:	Mon, 28 May 2012 11:06:25 +0200
From:	Juri Lelli <juri.lelli@...il.com>
To:	Peter Zijlstra <peterz@...radead.org>
CC:	tglx@...utronix.de, mingo@...hat.com, rostedt@...dmis.org,
	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,
	jkacur@...hat.com, harald.gustafsson@...csson.com
Subject: Re: [RFC][PATCH 00/15] sched: SCHED_DEADLINE v5

Hi,

On 05/25/2012 12:42 PM, Peter Zijlstra wrote:
> On Wed, 2012-05-23 at 23:42 +0200, Juri Lelli wrote:
>> Still missing/incomplete:
>>    - (c)group based bandwidth management, and maybe scheduling;
>
> The b/w stuff for cgroups shouldn't be particularly hard, right? It
> shouldn't be more than ensuring the utilization sum of all children
> stays below the set value.
>
> Or am I missing something?
>

Yes, the sum of the bandwidths of entities (tasks and groups) belonging
to a group stays below its own set bandwidth. Actually, I quoted this
sentence from code that was included in previous versions (removed since
v3). I tried to build historical reasons why it was removed, but I failed
:-). Anyway, shouldn't be too hard to adapt that code to the new version
and see if it will raise any new concern.

>>    - bandwidth inheritance (to replace deadline/priority inheritance);
>
> Yes please, but this is somewhat longer term, I think the band-aids in
> place are sufficient to allow us to move fwd.
>

Yes, but I fear it could affect next point. Anyway, I agree that this is
something that I would consider long-term.

>>    - access control for non-root users (and related security concerns to
>>      address).
>
> Right, so could you detail what all is needed to allow regular users to
> create dl tasks?
>

Ok, I'll try to summarize what I think it would be a _minimal_ set of
requirements:

  o  define deadline(period) and runtime utilization caps; as it was in v3,
     RLIMIT_DLDLINE would be the minimum value a user task can use as its
     own deadline, while (as you pointed out) RLIMIT_DLRTIME would be a per
     user utilization cap, but it would also be tracked in user_struct to
     enforce a max utilization cap per user.
  
  o  At server parameters change/destruction some mechanism is needed to
     prevent possible attacks such as (ref. Tommaso's paper):

        - an app creates a task with an associated server;
        - when the runtime (budget) is about to be exhausted, the app
          destroys the server, returning the task to the default sched
          policy;
        - then, the app immediately creates a new server for the task,
          and keeps repeating the loop over and over.

     A possible solution is that, whenever a server is destroyed, the
     system doesn't completely forget about its existence, but it must
     continue to consider its utilization as not available until the
     next server period expired.
  
  o  The only "big problem" I fear is related to the current deadline
     inheritance mechanism. As Steven pointed out during the last review,
     a task could force more bandwidth than was allowed if:

        - it takes a futex;
        - it is boosted while holding it;
        - never releases the futex;

     and this is sadly achievable since, if boosted, a task inherits top
     waiter parameters and the enforcement mechanism is temporarily
     disabled for it.
  
Thanks and regards,

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