All of lore.kernel.org
 help / color / mirror / Atom feed
From: Kirill Tkhai <tkhai@yandex.ru>
To: Peter Zijlstra <peterz@infradead.org>
Cc: Ingo Molnar <mingo@kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Steven Rostedt <rostedt@goodmis.org>,
	"stable@vger.kernel.org" <stable@vger.kernel.org>
Subject: Re: [PATCH] sched/rt: Fix rq's cpupri leak while enqueue/dequeue child RT entities
Date: Tue, 17 Dec 2013 17:08:02 +0400	[thread overview]
Message-ID: <96341387285682@web18g.yandex.ru> (raw)
In-Reply-To: <20131217124656.GI21999@twins.programming.kicks-ass.net>

17.12.2013, 16:47, "Peter Zijlstra" <peterz@infradead.org>:
> On Tue, Dec 17, 2013 at 04:02:58PM +0400, Kirill Tkhai wrote:
>
>>  13.12.2013, 19:42, "Peter Zijlstra" <peterz@infradead.org>:
>>>  On Wed, Nov 27, 2013 at 07:59:13PM +0400, Kirill Tkhai wrote:
>>>>   This patch touches RT group scheduling case.
>>>>
>>>>   Functions inc_rt_prio_smp() and dec_rt_prio_smp() change (global) rq's priority,
>>>>   while rt_rq passed to them may be not the top-level rt_rq. This is wrong, because
>>>>   changing of priority on a child level does not guarantee that the priority is
>>>>   the highest all over the rq. So, this leak makes RT balancing unusable.
>>>>
>>>>   The short example: the task having the highest priority among all rq's RT tasks
>>>>   (no one other task has the same priority) are waking on a throttle rt_rq.
>>>>   The rq's cpupri is set to the task's priority equivalent, but real
>>>>   rq->rt.highest_prio.curr is less.
>>>>
>>>>   The patch below fixes the problem.
>>>>
>>>>   It looks like all version have this bug, so I CC'ed stable mailing list.
>>>  Yeah, I think this is right.
>>>
>>>  cpupri stuff should indeed only be changed for the top level group.
>>  Ingo, are you going to apply this patch? Or will you give any comments?
>
> I queued it, Ingo should get it through me somewhere today if all things
> go well.
>
> Thanks

Thanks, Peter


WARNING: multiple messages have this Message-ID (diff)
From: Kirill Tkhai <tkhai@yandex.ru>
To: Peter Zijlstra <peterz@infradead.org>
Cc: Ingo Molnar <mingo@kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Steven Rostedt <rostedt@goodmis.org>,
	"stable@vger.kernel.org" <stable@vger.kernel.org>
Subject: Re: [PATCH] sched/rt: Fix rq's cpupri leak while enqueue/dequeue child RT entities
Date: Tue, 17 Dec 2013 17:08:02 +0400	[thread overview]
Message-ID: <96341387285682@web18g.yandex.ru> (raw)
In-Reply-To: <20131217124656.GI21999@twins.programming.kicks-ass.net>

17.12.2013, 16:47, "Peter Zijlstra" <peterz@infradead.org>:
> On Tue, Dec 17, 2013 at 04:02:58PM +0400, Kirill Tkhai wrote:
>
>> О©╫13.12.2013, 19:42, "Peter Zijlstra" <peterz@infradead.org>:
>>> О©╫On Wed, Nov 27, 2013 at 07:59:13PM +0400, Kirill Tkhai wrote:
>>>> О©╫О©╫This patch touches RT group scheduling case.
>>>>
>>>> О©╫О©╫Functions inc_rt_prio_smp() and dec_rt_prio_smp() change (global) rq's priority,
>>>> О©╫О©╫while rt_rq passed to them may be not the top-level rt_rq. This is wrong, because
>>>> О©╫О©╫changing of priority on a child level does not guarantee that the priority is
>>>> О©╫О©╫the highest all over the rq. So, this leak makes RT balancing unusable.
>>>>
>>>> О©╫О©╫The short example: the task having the highest priority among all rq's RT tasks
>>>> О©╫О©╫(no one other task has the same priority) are waking on a throttle rt_rq.
>>>> О©╫О©╫The rq's cpupri is set to the task's priority equivalent, but real
>>>> О©╫О©╫rq->rt.highest_prio.curr is less.
>>>>
>>>> О©╫О©╫The patch below fixes the problem.
>>>>
>>>> О©╫О©╫It looks like all version have this bug, so I CC'ed stable mailing list.
>>> О©╫Yeah, I think this is right.
>>>
>>> О©╫cpupri stuff should indeed only be changed for the top level group.
>> О©╫Ingo, are you going to apply this patch? Or will you give any comments?
>
> I queued it, Ingo should get it through me somewhere today if all things
> go well.
>
> Thanks

Thanks, Peter


  reply	other threads:[~2013-12-17 13:08 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-11-27 15:59 [PATCH] sched/rt: Fix rq's cpupri leak while enqueue/dequeue child RT entities Kirill Tkhai
2013-12-12 10:30 ` Kirill Tkhai
2013-12-13 15:42 ` Peter Zijlstra
2013-12-17 12:02   ` Kirill Tkhai
2013-12-17 12:02     ` Kirill Tkhai
2013-12-17 12:46     ` Peter Zijlstra
2013-12-17 12:46       ` Peter Zijlstra
2013-12-17 13:08       ` Kirill Tkhai [this message]
2013-12-17 13:08         ` Kirill Tkhai
2013-12-18 10:32 ` [tip:sched/core] sched/rt: Fix rq's cpupri leak while enqueue/ dequeue " tip-bot for 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:
  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=96341387285682@web18g.yandex.ru \
    --to=tkhai@yandex.ru \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@kernel.org \
    --cc=peterz@infradead.org \
    --cc=rostedt@goodmis.org \
    --cc=stable@vger.kernel.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.