From: Juri Lelli <juri.lelli@redhat.com> To: Peter Zijlstra <peterz@infradead.org>, Ingo Molnar <mingo@kernel.org>, Qais Yousef <qyousef@layalina.io>, Waiman Long <longman@redhat.com>, Tejun Heo <tj@kernel.org>, Zefan Li <lizefan.x@bytedance.com>, Johannes Weiner <hannes@cmpxchg.org>, Hao Luo <haoluo@google.com> Cc: Dietmar Eggemann <dietmar.eggemann@arm.com>, Steven Rostedt <rostedt@goodmis.org>, linux-kernel@vger.kernel.org, luca.abeni@santannapisa.it, claudio@evidence.eu.com, tommaso.cucinotta@santannapisa.it, bristot@redhat.com, mathieu.poirier@linaro.org, cgroups@vger.kernel.org, Vincent Guittot <vincent.guittot@linaro.org>, Wei Wang <wvw@google.com>, Rick Yiu <rickyiu@google.com>, Quentin Perret <qperret@google.com>, Heiko Carstens <hca@linux.ibm.com>, Vasily Gorbik <gor@linux.ibm.com>, Alexander Gordeev <agordeev@linux.ibm.com>, Sudeep Holla <sudeep.holla@arm.com>, Juri Lelli <juri.lelli@redhat.com> Subject: [RFC PATCH 0/3] sched/deadline: cpuset: Rework DEADLINE bandwidth restoration Date: Wed, 15 Mar 2023 12:18:09 +0000 [thread overview] Message-ID: <20230315121812.206079-1-juri.lelli@redhat.com> (raw) Qais reported [1] that iterating over all tasks when rebuilding root 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 I instead would propose we 1 - 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) 2 - Keep track of the number of DEADLINE tasks belonging to each cpuset 3 - 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 This set is also available from https://github.com/jlelli/linux.git deadline/rework-cpusets Feedback is more than welcome. Best, Juri 1 - https://lore.kernel.org/lkml/20230206221428.2125324-1-qyousef@layalina.io/ Juri Lelli (3): sched/cpuset: Bring back cpuset_mutex sched/cpuset: Keep track of SCHED_DEADLINE task in cpusets cgroup/cpuset: Iterate only if DEADLINE tasks are present include/linux/cpuset.h | 12 ++- kernel/cgroup/cgroup.c | 4 + kernel/cgroup/cpuset.c | 175 +++++++++++++++++++++++------------------ kernel/sched/core.c | 32 ++++++-- 4 files changed, 137 insertions(+), 86 deletions(-) -- 2.39.2
WARNING: multiple messages have this Message-ID (diff)
From: Juri Lelli <juri.lelli-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> To: Peter Zijlstra <peterz-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org>, Ingo Molnar <mingo-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>, Qais Yousef <qyousef-wp2msK0BRk8tq7phqP6ubQ@public.gmane.org>, Waiman Long <longman-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>, Tejun Heo <tj-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>, Zefan Li <lizefan.x-EC8Uxl6Npydl57MIdRCFDg@public.gmane.org>, Johannes Weiner <hannes-druUgvl0LCNAfugRpC6u6w@public.gmane.org>, Hao Luo <haoluo-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org> Cc: Dietmar Eggemann <dietmar.eggemann-5wv7dgnIgG8@public.gmane.org>, Steven Rostedt <rostedt-nx8X9YLhiw1AfugRpC6u6w@public.gmane.org>, linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, luca.abeni-5rdYK369eBLQB0XuIGIEkQ@public.gmane.org, claudio-YOzL5CV4y4YG1A2ADO40+w@public.gmane.org, tommaso.cucinotta-5rdYK369eBLQB0XuIGIEkQ@public.gmane.org, bristot-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org, mathieu.poirier-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org, cgroups-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Vincent Guittot <vincent.guittot-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>, Wei Wang <wvw-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org>, Rick Yiu <rickyiu-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org>, Quentin Perret <qperret-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org>, Heiko Carstens <hca-tEXmvtCZX7AybS5Ee8rs3A@public.gmane.org>, Vasily Gorbik <gor-tEXmvtCZX7AybS5Ee8rs3A@public.gmane.org>, Alexander Gordeev <agordeev-tEXmvtCZX7AybS5Ee8rs3A@public.gmane.org>, Sudeep Holla <sudeep.holla-5wv7dgnIgG8@public.gmane.org>, Juri Lelli <juri.lelli-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> Subject: [RFC PATCH 0/3] sched/deadline: cpuset: Rework DEADLINE bandwidth restoration Date: Wed, 15 Mar 2023 12:18:09 +0000 [thread overview] Message-ID: <20230315121812.206079-1-juri.lelli@redhat.com> (raw) Qais reported [1] that iterating over all tasks when rebuilding root 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 I instead would propose we 1 - 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) 2 - Keep track of the number of DEADLINE tasks belonging to each cpuset 3 - 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 This set is also available from https://github.com/jlelli/linux.git deadline/rework-cpusets Feedback is more than welcome. Best, Juri 1 - https://lore.kernel.org/lkml/20230206221428.2125324-1-qyousef-wp2msK0BRk8tq7phqP6ubQ@public.gmane.org/ Juri Lelli (3): sched/cpuset: Bring back cpuset_mutex sched/cpuset: Keep track of SCHED_DEADLINE task in cpusets cgroup/cpuset: Iterate only if DEADLINE tasks are present include/linux/cpuset.h | 12 ++- kernel/cgroup/cgroup.c | 4 + kernel/cgroup/cpuset.c | 175 +++++++++++++++++++++++------------------ kernel/sched/core.c | 32 ++++++-- 4 files changed, 137 insertions(+), 86 deletions(-) -- 2.39.2
next reply other threads:[~2023-03-15 12:20 UTC|newest] Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top 2023-03-15 12:18 Juri Lelli [this message] 2023-03-15 12:18 ` [RFC PATCH 0/3] sched/deadline: cpuset: Rework DEADLINE bandwidth restoration Juri Lelli 2023-03-15 12:18 ` [RFC PATCH 1/3] sched/cpuset: Bring back cpuset_mutex Juri Lelli 2023-03-15 12:18 ` Juri Lelli 2023-03-15 12:18 ` [RFC PATCH 2/3] sched/cpuset: Keep track of SCHED_DEADLINE tasks in cpusets Juri Lelli 2023-03-15 12:18 ` Juri Lelli 2023-03-15 14:49 ` Qais Yousef 2023-03-15 14:49 ` Qais Yousef 2023-03-15 17:18 ` Juri Lelli 2023-03-15 17:18 ` Juri Lelli 2023-03-15 19:25 ` Qais Yousef 2023-03-15 19:25 ` Qais Yousef 2023-03-15 15:46 ` Waiman Long 2023-03-15 15:46 ` Waiman Long 2023-03-15 17:14 ` Juri Lelli 2023-03-15 17:14 ` Juri Lelli 2023-03-15 18:01 ` Waiman Long 2023-03-15 18:01 ` Waiman Long 2023-03-15 18:10 ` Waiman Long 2023-03-15 18:10 ` Waiman Long 2023-03-15 23:27 ` Waiman Long 2023-03-15 23:27 ` Waiman Long 2023-03-22 14:05 ` Dietmar Eggemann 2023-03-22 14:05 ` Dietmar Eggemann 2023-03-22 13:18 ` Dietmar Eggemann 2023-03-22 13:18 ` Dietmar Eggemann 2023-03-15 12:18 ` [RFC PATCH 3/3] cgroup/cpuset: Iterate only if DEADLINE tasks are present Juri Lelli 2023-03-15 12:18 ` Juri Lelli 2023-03-15 14:55 ` [RFC PATCH 0/3] sched/deadline: cpuset: Rework DEADLINE bandwidth restoration Qais Yousef 2023-03-15 14:55 ` Qais Yousef 2023-03-15 17:10 ` Juri Lelli 2023-03-15 17:10 ` Juri Lelli
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=20230315121812.206079-1-juri.lelli@redhat.com \ --to=juri.lelli@redhat.com \ --cc=agordeev@linux.ibm.com \ --cc=bristot@redhat.com \ --cc=cgroups@vger.kernel.org \ --cc=claudio@evidence.eu.com \ --cc=dietmar.eggemann@arm.com \ --cc=gor@linux.ibm.com \ --cc=hannes@cmpxchg.org \ --cc=haoluo@google.com \ --cc=hca@linux.ibm.com \ --cc=linux-kernel@vger.kernel.org \ --cc=lizefan.x@bytedance.com \ --cc=longman@redhat.com \ --cc=luca.abeni@santannapisa.it \ --cc=mathieu.poirier@linaro.org \ --cc=mingo@kernel.org \ --cc=peterz@infradead.org \ --cc=qperret@google.com \ --cc=qyousef@layalina.io \ --cc=rickyiu@google.com \ --cc=rostedt@goodmis.org \ --cc=sudeep.holla@arm.com \ --cc=tj@kernel.org \ --cc=tommaso.cucinotta@santannapisa.it \ --cc=vincent.guittot@linaro.org \ --cc=wvw@google.com \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.