linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Christoph Lameter <cl@linux.com>
To: Steven Rostedt <rostedt@goodmis.org>
Cc: Daniel Bristot de Oliveira <bristot@redhat.com>,
	Ingo Molnar <mingo@redhat.com>,
	Peter Zijlstra <peterz@infradead.org>,
	linux-rt-users <linux-rt-users@vger.kernel.org>,
	LKML <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] sched/rt: RT_RUNTIME_GREED sched feature
Date: Mon, 7 Nov 2016 13:30:15 -0600 (CST)	[thread overview]
Message-ID: <alpine.DEB.2.20.1611071328470.19249@east.gentwo.org> (raw)
In-Reply-To: <20161107133207.4282de69@gandalf.local.home>

On Mon, 7 Nov 2016, Steven Rostedt wrote:

> On Mon, 7 Nov 2016 10:55:38 -0600 (CST)
> Christoph Lameter <cl@linux.com> wrote:
>
> > On Mon, 7 Nov 2016, Daniel Bristot de Oliveira wrote:
> >
> > > With these two options set, the user will guarantee some runtime
> > > for non-rt-tasks on all CPUs, while keeping real-time tasks running
> > > as much as possible.
> >
> > Excellent this would improve the situation with deadlocks as a result of
> > cgroup_locks not being released due to lack of workqueue processing.
>
> ?? What deadlocks do you see? I mean, can you show the situation that
> throttling RT tasks will cause deadlock?
>
> Sorry, but I'm just not seeing it.

SCHED_RR tasks alternately running on on cpu can cause endless deferral of
kworker threads. With the global effect of the OS processing reserved
it may be the case that the processor we are executing never gets any
time. And if that kworker threads role is releasing a mutex (like the
cgroup_lock) then deadlocks can result.

  parent reply	other threads:[~2016-11-07 19:30 UTC|newest]

Thread overview: 37+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-11-07  8:17 [PATCH] sched/rt: RT_RUNTIME_GREED sched feature Daniel Bristot de Oliveira
2016-11-07 10:31 ` Tommaso Cucinotta
2016-11-07 13:51   ` Daniel Bristot de Oliveira
2016-11-07 18:03     ` Tommaso Cucinotta
2016-11-07 18:06       ` Luca Abeni
2016-11-08  7:55     ` luca abeni
2016-11-08 10:30     ` Juri Lelli
2016-11-07 16:55 ` Christoph Lameter
2016-11-07 18:32   ` Steven Rostedt
2016-11-07 18:49     ` Daniel Bristot de Oliveira
2016-11-07 19:16       ` Steven Rostedt
2016-11-07 19:30     ` Christoph Lameter [this message]
2016-11-07 19:47       ` Steven Rostedt
2016-11-07 19:54         ` Christoph Lameter
2016-11-07 20:00           ` Steven Rostedt
2016-11-07 20:06             ` Daniel Bristot de Oliveira
2016-11-07 20:16               ` Steven Rostedt
2016-11-07 20:33                 ` Daniel Bristot de Oliveira
2016-11-07 20:44                   ` Steven Rostedt
2016-11-08  9:22                     ` [PATCH] sched/rt: Change default setup for RT THROTTLING Daniel Bristot de Oliveira
2016-11-08 23:42                 ` [PATCH] sched/rt: RT_RUNTIME_GREED sched feature Christoph Lameter
2016-11-07 18:22 ` Clark Williams
2016-11-07 18:30   ` Steven Rostedt
2016-11-07 18:38     ` Daniel Bristot de Oliveira
2016-11-07 18:39     ` Clark Williams
2016-11-08 11:59 ` Peter Zijlstra
2016-11-08 14:07   ` Steven Rostedt
2016-11-08 16:51     ` Peter Zijlstra
2016-11-08 17:17       ` Steven Rostedt
2016-11-08 18:05         ` Peter Zijlstra
2016-11-08 19:29           ` Daniel Bristot de Oliveira
2016-11-08 19:50             ` Peter Zijlstra
2016-11-09 13:33               ` Daniel Bristot de Oliveira
     [not found]                 ` <CAA7rmPF0nQb9721MQWurRCy7E3X46hAy2qV=joK=z5U-t70NOg@mail.gmail.com>
2016-11-11 18:46                   ` Christoph Lameter
2016-11-11 22:53                     ` Peter Zijlstra
2016-11-13 18:53                       ` Christoph Lameter
2016-11-14  9:20                         ` 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=alpine.DEB.2.20.1611071328470.19249@east.gentwo.org \
    --to=cl@linux.com \
    --cc=bristot@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-rt-users@vger.kernel.org \
    --cc=mingo@redhat.com \
    --cc=peterz@infradead.org \
    --cc=rostedt@goodmis.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;
as well as URLs for NNTP newsgroup(s).