From: Tobias Huschle <huschle@linux.ibm.com>
To: linux-kernel@vger.kernel.org
Cc: mingo@redhat.com, peterz@infradead.org, juri.lelli@redhat.com,
vincent.guittot@linaro.org, dietmar.eggemann@arm.com,
rostedt@goodmis.org, bsegall@google.com, mgorman@suse.de,
bristot@redhat.com, vschneid@redhat.com,
sshegde@linux.vnet.ibm.com, srikar@linux.vnet.ibm.com,
linuxppc-dev@lists.ozlabs.org
Subject: [RFC 0/1] sched/fair: Consider asymmetric scheduler groups in load balancer
Date: Mon, 15 May 2023 13:46:00 +0200 [thread overview]
Message-ID: <20230515114601.12737-1-huschle@linux.ibm.com> (raw)
The current load balancer implementation implies that scheduler groups,
within the same scheduler domain, all host the same number of CPUs.
This appears to be valid for non-s390 architectures. Nevertheless, s390
can actually have scheduler groups of unequal size.
The current scheduler behavior causes some s390 configs to use SMT
while some cores are still idle, leading to a performance degredation
under certain levels of workload.
Please refer to the patch's commit message for more details and an
example. This patch is a proposal on how to integrate the size of
scheduler groups into the decision process.
This patch is the most basic approach to address this issue and does
not claim to be perfect as-is.
Other ideas that also proved to address the problem but are more
complex but also potentially more precise:
1. On scheduler group building, count the number of CPUs within each
group that are first in their sibling mask. This represents the
number of CPUs that can be used before running into SMT. This
should be slightly more accurate than using the full group weight
if the number of available SMT threads per core varies.
2. Introduce a new scheduler group classification (smt_busy) in
between of fully_busy and has_spare. This classification would
indicate that a group still has spare capacity, but will run
into SMT when using that capacity. This would make the load
balancer prefer groups with fully idle CPUs over ones that are
about to run into SMT.
Feedback would be greatly appreciated.
Tobias Huschle (1):
sched/fair: Consider asymmetric scheduler groups in load balancer
kernel/sched/fair.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
--
2.34.1
next reply other threads:[~2023-05-15 11:55 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-05-15 11:46 Tobias Huschle [this message]
2023-05-15 11:46 ` [RFC 1/1] sched/fair: Consider asymmetric scheduler groups in load balancer Tobias Huschle
2023-05-16 13:36 ` Vincent Guittot
2023-06-05 8:07 ` Tobias Huschle
2023-07-05 7:52 ` Vincent Guittot
2023-07-07 7:44 ` Tobias Huschle
2023-07-07 14:33 ` Shrikanth Hegde
2023-07-07 15:59 ` Tobias Huschle
2023-07-07 16:26 ` Shrikanth Hegde
2023-07-04 13:40 ` Peter Zijlstra
2023-07-07 7:44 ` Tobias Huschle
2023-07-06 17:19 ` Shrikanth Hegde
2023-07-07 7:45 ` Tobias Huschle
2023-05-16 16:35 ` [RFC 0/1] " Dietmar Eggemann
2023-07-04 9:11 ` Tobias Huschle
2023-07-06 11:11 ` Dietmar Eggemann
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=20230515114601.12737-1-huschle@linux.ibm.com \
--to=huschle@linux.ibm.com \
--cc=bristot@redhat.com \
--cc=bsegall@google.com \
--cc=dietmar.eggemann@arm.com \
--cc=juri.lelli@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=mgorman@suse.de \
--cc=mingo@redhat.com \
--cc=peterz@infradead.org \
--cc=rostedt@goodmis.org \
--cc=srikar@linux.vnet.ibm.com \
--cc=sshegde@linux.vnet.ibm.com \
--cc=vincent.guittot@linaro.org \
--cc=vschneid@redhat.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: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox