All of lore.kernel.org
 help / color / mirror / Atom feed
From: Daniel Wagner <daniel.wagner@bmw-carit.de>
To: Peter Zijlstra <peterz@infradead.org>
Cc: <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v1 3/8] sched/completion: convert completions to use simple wait queues
Date: Mon, 12 Oct 2015 14:44:28 +0200	[thread overview]
Message-ID: <561BAB2C.9020000@bmw-carit.de> (raw)
In-Reply-To: <20151012115829.GN3816@twins.programming.kicks-ass.net>

On 10/12/2015 01:58 PM, Peter Zijlstra wrote:
> On Mon, Oct 12, 2015 at 12:03:06PM +0200, Daniel Wagner wrote:
>> On 10/12/2015 11:17 AM, Daniel Wagner wrote:
>>> On 09/09/2015 04:26 PM, Peter Zijlstra wrote:
>>>> On Wed, Sep 09, 2015 at 02:05:29PM +0200, Daniel Wagner wrote:
>>>>> @@ -50,10 +50,10 @@ void complete_all(struct completion *x)
>>>>>  {
>>>>>  	unsigned long flags;
>>>>>  
>>>>> -	spin_lock_irqsave(&x->wait.lock, flags);
>>>>> +	raw_spin_lock_irqsave(&x->wait.lock, flags);
>>>>>  	x->done += UINT_MAX/2;
>>>>> -	__wake_up_locked(&x->wait, TASK_NORMAL, 0);
>>>>> -	spin_unlock_irqrestore(&x->wait.lock, flags);
>>>>> +	swake_up_locked(&x->wait);
>>>>> +	raw_spin_unlock_irqrestore(&x->wait.lock, flags);
>>>>>  }
>>>>>  EXPORT_SYMBOL(complete_all);
>>>>
>>>> I don't think that's correct; __wake_up_locked(.nr=0) would wake all
>>>> waiters, where swake_up_locked() will only wake one.
>>>
>>> I read that x->done should be protected via wait.lock during the whole
>>> operation. swake_up_all() will release and reacquire the lock while
>>> processing the all waiters. So we need to get
>>>
>>> Could we play a trick like setting the highest bit in done for
>>> indicating the complete_all() operation. The UINT_MAX/2 update looks
>>> like do this by setting a value which has the biggest offset from 0 (but
>>> why adding instead of just going for assigning...).
>>
>>
>> I had something like this here in mind:
> 
> I'm not exactly sure what problem you're trying to solve here.. The fact
> that we cannot call swake_all() while holding &x->wait.lock, or the fact
> that complete_all() is typically called from a context which cannot do
> swake_all() either?

The first one.

> Note:
> 
> Documentation/scheduler/completion.txt:complete() and complete_all() can be called in hard-irq/atomic context safely.
> 
> Which is very much _NOT_ true of swake_all().

Heh and I thought I got this right.

Looks like completion.c cannot use swait here. Or do you have an idea
how to do it? I was thinking on deferring the wake all call from
hard-irq/atomic but I guess this something to avoided.

cheers,
daniel

  reply	other threads:[~2015-10-12 12:44 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-09-09 12:05 [PATCH v0 0/8] Simple wait queue support Daniel Wagner
2015-09-09 12:05 ` [PATCH v1 1/8] wait.[ch]: Introduce the simple waitqueue (swait) implementation Daniel Wagner
2015-09-09 12:05 ` [PATCH v1 2/8] KVM: use simple waitqueue for vcpu->wq Daniel Wagner
2015-09-09 12:05 ` [PATCH v1 3/8] sched/completion: convert completions to use simple wait queues Daniel Wagner
2015-09-09 14:26   ` Peter Zijlstra
2015-10-12  9:17     ` Daniel Wagner
2015-10-12 10:03       ` Daniel Wagner
2015-10-12 11:58         ` Peter Zijlstra
2015-10-12 12:44           ` Daniel Wagner [this message]
2015-09-09 12:05 ` [PATCH v1 4/8] rcu: use simple wait queues where possible in rcutree Daniel Wagner
2015-09-09 12:05 ` [PATCH v1 5/8] rcu: Do not call swake_up_all with rnp->lock holding Daniel Wagner
2015-09-09 12:05 ` [PATCH v1 6/8] gadgetfs: Fix fallout of wait to swait completion change Daniel Wagner
2015-09-09 12:05 ` [PATCH v1 7/8] usb: gadget: f_fs: " Daniel Wagner
2015-09-09 12:05 ` [PATCH v1 8/8] orinoco_usb: " Daniel Wagner

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=561BAB2C.9020000@bmw-carit.de \
    --to=daniel.wagner@bmw-carit.de \
    --cc=linux-kernel@vger.kernel.org \
    --cc=peterz@infradead.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.