LKML Archive on
help / color / mirror / Atom feed
From: Kirill Tkhai <>
To: Juri Lelli <>
Subject: Re: [PATCH] sched/rt: Rework for_each_process_thread() iterations in tg_has_rt_tasks()
Date: Fri, 20 Apr 2018 14:21:30 +0300	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <20180420105852.GH24599@localhost.localdomain>

On 20.04.2018 13:58, Juri Lelli wrote:
> On 20/04/18 12:43, Kirill Tkhai wrote:
>> On 20.04.2018 12:25, Juri Lelli wrote:
> [...]
>>> Isn't this however checking against the current (dynamic) number of
>>> runnable tasks/groups instead of the "static" group membership (which
>>> shouldn't be affected by a task running state)?
>> Ah, you are sure. I forgot that rt_nr_running does not contain sleeping tasks.
>> We need to check something else here. I'll try to find another way.
> n/p. Maybe a per rt_rq flag linked to "static" membership (I didn't
> really thought this through though :).

sched_move_task() does not change any rt_rq's fields on moving a dequeued
task, so we definitely can't use rt_rq to detect all the tasks.

> BTW, since you faced this problem, I guess this is on RT_GROUP_SCHED
> enabled boxes, so I'd have a couple of questions (not strictly related
> to the problem at hand):
>  - do such boxes rely on RT throttling being performed at root level?
>  - is RT_RUNTIME_SHARE enabled?

This is a machine with many fair_sched_class tasks, while there are no
(almost) RT tasks there, and there is no "real" real-time with throttling.
They are not interesting from this point of view. Very small number
of task group may have rt_runtime != 0 there, and where so, rt_runtime value
is small. The problem I'm solving happened, when rt_period of one of such groups
were restored, and it hanged for ages, because of enormous number of child
cgroups and tasks (of fair_sched_class) in system.

RT_RUNTIME_SHARE is not enabled, as it's RH7-based 3.10 kernel.

Really, it will be very difficult to provide real-time on machines with
such the big number of tasks, in case of tasks allocates some resources
(not all the memory are pinned from going to slab, there is some IO, etc),
since there are some tasks-to-solve even in !rt case.


  reply	other threads:[~2018-04-20 11:21 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-04-19 17:29 Kirill Tkhai
2018-04-20  9:25 ` Juri Lelli
2018-04-20  9:43   ` Kirill Tkhai
2018-04-20 10:06     ` [PATCH v2] " Kirill Tkhai
2018-04-20 14:11       ` Juri Lelli
2018-04-20 14:30         ` Kirill Tkhai
2018-04-20 15:27           ` Juri Lelli
2018-04-25 15:42       ` Kirill Tkhai
2018-04-25 19:49       ` Peter Zijlstra
2018-04-26  9:54         ` [PATCH v3]sched/rt: Stop " Kirill Tkhai
2020-01-23 21:56           ` Phil Auld
2020-01-24  9:09             ` Kirill Tkhai
2020-01-27 16:30               ` Phil Auld
2020-01-27 16:43             ` Peter Zijlstra
2020-01-27 16:56               ` Phil Auld
2020-01-27 17:00                 ` Peter Zijlstra
2020-01-27 17:45                   ` Phil Auld
2018-04-20 10:58     ` [PATCH] sched/rt: Rework " Juri Lelli
2018-04-20 11:21       ` Kirill Tkhai [this message]
2018-04-25 17:55 ` Peter Zijlstra
2018-04-26  9:26   ` Kirill Tkhai

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:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \ \ \
    --subject='Re: [PATCH] sched/rt: Rework for_each_process_thread() iterations in tg_has_rt_tasks()' \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).