Hi, On 12/02/18 08:47, Tejun Heo wrote: > Hello, > > On Mon, Feb 12, 2018 at 02:40:29PM +0100, Juri Lelli wrote: > > - implementation _is not_ hierarchical: only single/plain DEADLINE entities > > can be handled, and they get scheduled at root rq level > > This usually is a deal breaker and often indicates that the cgroup > filesystem is not the right interface for the feature. Can you please > elaborate the interface with some details?
The interface is the same as what we have today for groups of RT tasks, and same rules apply. The difference is that when using RT <group>/cpu.rt_runtime_us and <group>/cpu.rt_period_us control RT-Throttling behaviour (fraction of CPU time and granularity), while for DEADLINE the same interface would be used only at admission control time (while servicing a sched_setattr(), attaching tasks to a group or changing group's parameters) since DEADLINE task have their own throttling mechanism already. Intended usage should be very similar. For example, a sys admin that wants to reserve and guarantee CPU bandwidth for a group of tasks would create a group, configure its rt_runtime_us, rt_period_us and put DEADLINE tasks inside it (e.g. video/audio pipeline). Related to what I was saying in the cover letter (i.e., non root access to DEADLINE scheduling) might be a different situation, where sys admin wants to grant a user a certain percentage of CPU time (by creating a group and putting user session inside it) and also control that user doesn't exceed what granted. User would then be free to spawn DEADLINE tasks to service her/his needs up to the maximum bandwidth cap set by sys admin. Does this make any sense and provide a bit more information? Thanks a lot for looking at this! Best, - Juri