public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
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


             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