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 11:17:14 +0200 [thread overview]
Message-ID: <561B7A9A.3020904@bmw-carit.de> (raw)
In-Reply-To: <20150909142608.GP12596@twins.programming.kicks-ass.net>
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...).
cheers,
daniel
next prev parent reply other threads:[~2015-10-12 9:17 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 [this message]
2015-10-12 10:03 ` Daniel Wagner
2015-10-12 11:58 ` Peter Zijlstra
2015-10-12 12:44 ` Daniel Wagner
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=561B7A9A.3020904@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.