On Fri, Aug 07, 2020 at 11:56:04AM +0200, Juri Lelli wrote: > Starting deadline server for lower priority classes right away when > first task is enqueued might break guarantees, as tasks belonging to > intermediate priority classes could be uselessly preempted. E.g., a well > behaving (non hog) FIFO task can be preempted by NORMAL tasks even if > there are still CPU cycles available for NORMAL tasks to run, as they'll > be running inside the fair deadline server for some period of time. > > To prevent this issue, implement a starvation monitor mechanism that > starts the deadline server only if a (fair in this case) task hasn't > been scheduled for some interval of time after it has been enqueued. > Use pick/put functions to manage starvation monitor status. One thing I considerd was scheduling this as a least-laxity entity -- such that it runs late, not early -- and start the server when rq->nr_running != rq->cfs.h_nr_running, IOW when there's !fair tasks around. Not saying we should do it like that, but that's perhaps more deterministic than this.
