From: Joel Fernandes <joel@joelfernandes.org>
To: Peter Zijlstra <peterz@infradead.org>
Cc: LKML <linux-kernel@vger.kernel.org>,
Steven Rostedt <rostedt@goodmis.org>,
juri.lelli@redhat.com, vincent.guittot@linaro.org,
Youssef Esmat <youssefesmat@google.com>,
Dietmar Eggemann <dietmar.eggemann@arm.com>,
Thomas Gleixner <tglx@linutronix.de>
Subject: Sum of weights idea for CFS PI
Date: Thu, 29 Sep 2022 16:38:44 -0400 [thread overview]
Message-ID: <cb6c406e-1431-fcfd-ef82-87259760ead9@joelfernandes.org> (raw)
Hi Peter, all,
Just following-up about the idea Peter suggested at LPC22 about sum of weights
to solve the CFS priority inversion issues using priority inheritance. I am not
sure if a straight forward summation of the weights of dependencies in the
chain, is sufficient (or may cause too much unfairness).
I think it will work if all the tasks on CPU are 100% in utilization:
Say if you have 4 tasks (A, B, C, D) running and each one has equal
weight (W) except for A which has twice the weight (2W).
So the CPU bandwidth distribution is (assuming all are running):
A: 2 / 5
B, C. D: 1 / 5
Say out of the 4 tasks, 3 of them are a part of a classical priority
inversion scenario (A, B and C).
Say now A blocks on a lock and that lock's owner C is running, however now
because A has blocked, B gets 1/3 bandwidth, where as it should have been
limited to 1/5. To remedy this, say you give C a weight of 2W. B gets 1/4
bandwidth - still not fair since B is eating away CPU bandwidth causing the
priority inversion we want to remedy.
The correct bandwidth distribution should be (B and D should be unchanged):
B = 1/5
D = 1/5
C = 3/5
This means that C's weight should be 3W , and B and D should be W each
as before. So indeed, C's new weight is its original weight PLUS the
weight of the A - that's needed to keep the CPU usage of the other
tasks (B, D) in check so that C makes forward progress on behalf of A and the
other tasks don't eat into the CPU utilization.
However, I think this will kinda fall apart if A is asleep 50% of the time
(assume the sleep is because of I/O and unrelated to the PI chain).
Because now if all were running (and assume no PI dependencies), with A being
50%, the bandwidth of B, C and D each would be divided into 2 components:
a. when A is running, it would be as above.
b. but if A was sleeping, B, C, and D would get 1/3.
So on average, B, C and D get: (1/3 + 1/5) / 2 = 8/30. This gives A about 6/30
or 1/5 bandwidth.
But now say A happen to block on a lock that C is holding. You would boost C to
weight 3W which gives it 3/5 (or 18/30) as we saw above, which is more than what
C should actually get.
C should get (8/30 + 6/30 = 14/30) AFAICS.
Hopefully one can see that a straight summation of weights is not enough. It
needs to be something like:
C's new weight = C's original weight + (A's weight) * (A's utilization)
Or something, otherwise the inherited weight may be too much to properly solve it.
Any thoughts on this? You mentioned you had some notes on this and/or proxy
execution, could you share it?
Thanks,
- Joel
next reply other threads:[~2022-09-29 20:38 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-09-29 20:38 Joel Fernandes [this message]
2022-09-30 13:49 ` Qais Yousef
2022-09-30 15:44 ` Youssef Esmat
2022-09-30 17:42 ` Joel Fernandes
2022-09-30 18:10 ` Youssef Esmat
2022-09-30 18:45 ` Joel Fernandes
2022-09-30 17:34 ` Joel Fernandes
2022-10-03 16:14 ` Qais Yousef
2022-10-03 16:27 ` Joel Fernandes
2022-10-04 16:30 ` Qais Yousef
2022-10-04 19:48 ` Joel Fernandes
2022-10-05 9:31 ` Qais Yousef
2022-10-04 20:27 ` Joel Fernandes
2022-10-05 10:04 ` Qais Yousef
2022-10-06 13:53 ` Joel Fernandes
2022-10-06 19:40 ` Youssef Esmat
2022-10-08 15:04 ` Joel Fernandes
2022-10-10 14:46 ` Qais Yousef
2022-10-10 15:11 ` Joel Fernandes
2022-10-12 14:30 ` Qais Yousef
2022-10-04 11:50 ` Sebastian Andrzej Siewior
2022-10-04 14:43 ` Joel Fernandes
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=cb6c406e-1431-fcfd-ef82-87259760ead9@joelfernandes.org \
--to=joel@joelfernandes.org \
--cc=dietmar.eggemann@arm.com \
--cc=juri.lelli@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=peterz@infradead.org \
--cc=rostedt@goodmis.org \
--cc=tglx@linutronix.de \
--cc=vincent.guittot@linaro.org \
--cc=youssefesmat@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: 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
all inboxes | Powered by JetHome®