Re: [RFC][PATCH 00/15] sched: SCHED_DEADLINE v5

[Juri Lelli <juri.lelli@gmail.com>]

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