On 03/29/23 14:55, Juri Lelli wrote:
Qais reported [1] that iterating over all tasks when rebuilding rootIs this just waiting to be picked up or still there's something to be addressed
domains for finding out which ones are DEADLINE and need their bandwidth
correctly restored on such root domains can be a costly operation (10+
ms delays on suspend-resume). He proposed we skip rebuilding root
domains for certain operations, but that approach seemed arch specific
and possibly prone to errors, as paths that ultimately trigger a rebuild
might be quite convoluted (thanks Qais for spending time on this!).
To fix the problem
01/06 - Rename functions deadline with DEADLINE accounting (cleanup
suggested by Qais) - no functional change
02/06 - Bring back cpuset_mutex (so that we have write access to cpusets
from scheduler operations - and we also fix some problems
associated to percpu_cpuset_rwsem)
03/06 - Keep track of the number of DEADLINE tasks belonging to each cpuset
04/06 - Create DL BW alloc, free & check overflow interface for bulk
bandwidth allocation/removal - no functional change
05/06 - Fix bandwidth allocation handling for cgroup operation
involving multiple tasks
06/06 - Use this information to only perform the costly iteration if
DEADLINE tasks are actually present in the cpuset for which a
corresponding root domain is being rebuilt
With respect to the RFC posting [2]
1 - rename DEADLINE bandwidth accounting functions - Qais
2 - call inc/dec_dl_tasks_cs from switched_{to,from}_dl - Qais
3 - fix DEADLINE bandwidth allocation with multiple tasks - Waiman,
contributed by Dietmar
This set is also available from
https://github.com/jlelli/linux.git deadline/rework-cpusets
still?