public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Peter Zijlstra <peterz@infradead.org>
To: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Cc: Corey Minyard <cminyard@mvista.com>,
	Thomas Gleixner <tglx@linutronix.de>,
	Steven Rostedt <rostedt@goodmis.org>,
	linux-rt-users <linux-rt-users@vger.kernel.org>,
	linux-kernel <linux-kernel@vger.kernel.org>,
	Tejun Heo <tj@kernel.org>
Subject: Re: Warning from swake_up_all in 4.14.15-rt13 non-RT
Date: Mon, 12 Mar 2018 14:27:29 +0100	[thread overview]
Message-ID: <20180312132729.GI4064@hirez.programming.kicks-ass.net> (raw)
In-Reply-To: <20180312105113.p7jifhwdwbhpvxds@linutronix.de>

On Mon, Mar 12, 2018 at 11:51:13AM +0100, Sebastian Andrzej Siewior wrote:
> On 2018-03-09 23:26:43 [+0100], Peter Zijlstra wrote:
> > On Fri, Mar 09, 2018 at 09:25:50PM +0100, Sebastian Andrzej Siewior wrote:
> > > Is it just about the irqsave() usage or something else? I doubt it is
> > > the list walk. It is still unbound if not called from irq-off region.
> > 
> > The current list walk is preemptible. You put the entire iteration (of
> > unbound length) inside a single critical section which destroy RT.
> 
> I considered that list walk as cheap. We don't do any wake ups with the
> list walk - just mark the task for a later wake up. But if it is not I
> could add an upper limit of 20 iterations or so.

So the problem is that as soon as this is exposed to userspace you've
lost.

If a user can stack like 10000 tasks on the completion before triggering
it, you've got yourself a giant !preempt section. Yes the wake_q stuff
is cheaper, but unbound is still unbound.

wake_all must not be used from !preemptible (IRQ or otherwise) sections.
And I'm not seeing how waking just the top 20 helps.

> > Why isn't this a problem on RT?
> So we remain in the preempt_disable() section due to RCU-sched so we
> have this, yes. But the "disabled interrupts" part is due to
> spin_lock_irqsave() which is a non-issue on RT. So if we managed to get
> rid of the rcu-sched then the swait can go and we can stick with the
> wake_up_all() on RT, too.

OK, so for RT we simply loose the IRQ-disable thing, but its still a
!preemptible section.

  reply	other threads:[~2018-03-12 13:27 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-03-05 15:08 Warning from swake_up_all in 4.14.15-rt13 non-RT Corey Minyard
2018-03-06 17:46 ` Sebastian Andrzej Siewior
2018-03-06 22:51   ` Corey Minyard
2018-03-07 15:45   ` Corey Minyard
2018-03-08 17:41     ` Sebastian Andrzej Siewior
2018-03-08 19:54       ` Corey Minyard
2018-03-09 11:04         ` Sebastian Andrzej Siewior
2018-03-09 13:29           ` Corey Minyard
2018-03-09 14:58             ` Sebastian Andrzej Siewior
2018-03-09 16:03               ` Corey Minyard
2018-03-09 17:46           ` Peter Zijlstra
2018-03-09 20:25             ` Sebastian Andrzej Siewior
2018-03-09 22:26               ` Peter Zijlstra
2018-03-12 10:51                 ` Sebastian Andrzej Siewior
2018-03-12 13:27                   ` Peter Zijlstra [this message]
2018-03-12 14:11                     ` Sebastian Andrzej Siewior
2018-03-12 14:29                       ` Peter Zijlstra
2018-03-12 19:51                         ` Sebastian Andrzej Siewior
2018-03-13 18:40                           ` [RT PATCH 1/2] Revert "block: blk-mq: Use swait" Sebastian Andrzej Siewior
2018-03-13 18:42                             ` [RT PATCH 2/2] block: blk-mq: move blk_queue_usage_counter_release() into process context Sebastian Andrzej Siewior
2018-03-13 20:10                               ` Peter Zijlstra
2018-03-14 15:23                                 ` Sebastian Andrzej Siewior
2018-03-09 22:02             ` Warning from swake_up_all in 4.14.15-rt13 non-RT Corey Minyard

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=20180312132729.GI4064@hirez.programming.kicks-ass.net \
    --to=peterz@infradead.org \
    --cc=bigeasy@linutronix.de \
    --cc=cminyard@mvista.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-rt-users@vger.kernel.org \
    --cc=rostedt@goodmis.org \
    --cc=tglx@linutronix.de \
    --cc=tj@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox