From: Tommaso Cucinotta <tommaso.cucinotta@sssup.it>
To: Peter Zijlstra <peterz@infradead.org>
Cc: linux-kernel@vger.kernel.org
Subject: Re: 1 RT task blocks 4-core machine ?
Date: Sat, 09 Oct 2010 19:42:48 +0200 [thread overview]
Message-ID: <4CB0A998.3020407@sssup.it> (raw)
Peter wrote:
> On Tue, 2010-10-05 at 00:26 +0200, Tommaso Cucinotta wrote:
> > A possible explanation might be that the CFS load balancing logic sees
> > my only active task (e.g., the ssh server or shell etc.) as running
> > alone on its core, and does not detect that it is inhibited to actually
> > run due to RT tasks on the same core. Therefore, it will not migrate
> > the task to the free cores. Does this explanation make sense
> > or is it completely wrong ?
>
> Possibly, its got some logic to detect this but maybe it gets confused
> still, in particular look at the adaptive cpu_power in
> update_cpu_power() and calling functions.
Ok, I'll have a look (when I have some time :-( ), thanks.
> > Also, I'd like to hear whether this is considered the "normal/desired"
> > behavior of intermixing RT and non-RT tasks.
>
> Pegging a cpu using sched_fifo/rr pretty much means you get to keep the
> pieces, if it works nice, if you can make it work better kudos, but no
> polling from sched_fifo/rr is not something that is considered sane for
> the general health of your system.
Sure, I was not thinking to push/pull across heterogeneous scheduling
classes, but rather to simply account for the proper per-CPU tasks count
and load (including all the tasks comprising RT ones) when load-balancing
in CFS. Perhaps, you mean, e.g., if a RT task ends, the CPU would go idle
and it would be supposed to pull ? Just we don't do that, and at the next
load-balancing decision things would be fixed up (please, consider I don't
know the CFS load balancer so well).
So, for example, in addition to fix the reported issue, we'd get also that,
when pinning a heavy RT workload on a CPU, CFS tasks would migrate to other
CPUs, if available. Again, that doesn't need to be instantaneous (push), but
it could happen later when the CFS load-balancer is invoked (is it invoked
periodically, as of now ?).
Thanks,
T.
--
Tommaso Cucinotta, Computer Engineering PhD, Researcher
ReTiS Lab, Scuola Superiore Sant'Anna, Pisa, Italy
Tel +39 050 882 024, Fax +39 050 882 003
http://retis.sssup.it/people/tommaso
next reply other threads:[~2010-10-09 18:42 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-10-09 17:42 Tommaso Cucinotta [this message]
2010-10-11 7:53 ` 1 RT task blocks 4-core machine ? Peter Zijlstra
[not found] <AANLkTim2icGqFWB1S6TVcQwmo+sCcGdNDPO3s8LFqzR=@mail.gmail.com>
2010-10-04 22:26 ` Tommaso Cucinotta
2010-10-06 13:34 ` Peter Zijlstra
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=4CB0A998.3020407@sssup.it \
--to=tommaso.cucinotta@sssup.it \
--cc=linux-kernel@vger.kernel.org \
--cc=peterz@infradead.org \
/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