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

[Juri Lelli]

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@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/