All of lore.kernel.org
 help / color / mirror / Atom feed
From: Corey Minyard <cminyard@mvista.com>
To: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Cc: linux-rt-users <linux-rt-users@vger.kernel.org>,
	linux-kernel <linux-kernel@vger.kernel.org>,
	Tejun Heo <tj@kernel.org>, Peter Zijlstra <peterz@infradead.org>,
	Thomas Gleixner <tglx@linutronix.de>
Subject: Re: Warning from swake_up_all in 4.14.15-rt13 non-RT
Date: Thu, 8 Mar 2018 13:54:17 -0600	[thread overview]
Message-ID: <a11f140e-c44f-f967-1cd4-d8a6f09d4d29@mvista.com> (raw)
In-Reply-To: <20180308174103.mduy5qq2ttlcvig3@linutronix.de>

On 03/08/2018 11:41 AM, Sebastian Andrzej Siewior wrote:
> On 2018-03-07 09:45:29 [-0600], Corey Minyard wrote:
>>> I have no idea what is the wisest thing to do here. The obvious fix
>>> would be to use the irqsafe() variant here and not drop the lock between
>>> wake ups. That is essentially what swake_up_all_locked() does which I
>>> need for the completions (and based on some testing most users have one
>>> waiter except during PM and some crypto code).
>>> It is probably no comparison to wake_up_q() (which does multiple wake
>>> ups without a context switch) but then we did this before like that.
>>>
>>> Preferably we would have a proper list_splice() and some magic in the
>>> "early" dequeue part that works.
>>>
>> Maybe just modify the block code to run the swake_up_all() call in a
>> workqueue
>> or tasklet?  If you think that works, I'll create a patch, test it, and
>> submit it if
>> all goes well.
> It will work but I don't think pushing this into workqueue/tasklet is a
> good idea. You want to wakeup all waiters on waitqueue X (probably one
> waiter) and instead there is one one wakeup + ctx-switch which does the
> final wakeup.

True, but this is an uncommon and already fairly expensive operation being
done.  Adding a context switch doesn't seem that bad.

> But now I had an idea: swake_up_all() could iterate over list and
> instead performing wakes it would just wake_q_add() the tasks. Drop the
> lock and then wake_up_q(). So in case there is wakeup pending and the
> task removed itself from the list then the task may observe a spurious
> wakeup.

That sounds promising, but where does wake_up_q() get called?  No matter 
what
it's an expensive operation and I'm not sure where you would put it in 
this case.

I had another idea.  This is only occurring if RT is not enabled, 
because with
RT all the irq disable things go away and you are generally running in task
context.  So why not have a different version of swake_up_all() for non-RT
that does work from irqs-off context?

-corey

  reply	other threads:[~2018-03-08 19:54 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 [this message]
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
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=a11f140e-c44f-f967-1cd4-d8a6f09d4d29@mvista.com \
    --to=cminyard@mvista.com \
    --cc=bigeasy@linutronix.de \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-rt-users@vger.kernel.org \
    --cc=peterz@infradead.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 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.