On Mon, Jul 16, 2018 at 09:28:54AM +0100, Patrick Bellasi wrote: > This is a respin of: > > https://lore.kernel.org/lkml/[email protected] > > which addresses all the feedbacks collected from the LKML discussion as well > as during the presentation at last OSPM Summit: > > https://www.youtube.com/watch?v=0Yv9smm9i78 > > Further comments and feedbacks are more than welcome! > [...] > > Patrick Bellasi (12): > sched/core: uclamp: extend sched_setattr to support utilization > clamping > sched/core: uclamp: map TASK's clamp values into CPU's clamp groups > sched/core: uclamp: add CPU's clamp groups accounting > sched/core: uclamp: update CPU's refcount on clamp changes > sched/cpufreq: uclamp: add utilization clamping for FAIR tasks > sched/cpufreq: uclamp: add utilization clamping for RT tasks > sched/core: uclamp: enforce last task UCLAMP_MAX > sched/core: uclamp: extend cpu's cgroup controller > sched/core: uclamp: map TG's clamp values into CPU's clamp groups > sched/core: uclamp: use TG's clamps to restrict Task's clamps > sched/core: uclamp: update CPU's refcount on TG's clamp changes > sched/core: uclamp: use percentage clamp values > > Documentation/admin-guide/cgroup-v2.rst | 25 + > include/linux/sched.h | 53 ++ > include/uapi/linux/sched.h | 4 +- > include/uapi/linux/sched/types.h | 66 +- > init/Kconfig | 63 ++ > kernel/sched/core.c | 876 ++++++++++++++++++++++++
While I'm reviewing these patches, I had a quick thought. core.c is already 7k+ lines. Based on this diffstat, does it make sense for uclamp to be in its own kernel/sched/uclamp.c file? thanks, - Joel
