Messages in this thread |  | | | Date | Mon, 28 May 2012 11:06:25 +0200 | | From | Juri Lelli <> | | 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
|  |