From: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
To: Peter Zijlstra <peterz@infradead.org>, Daniel Wagner <wagi@monom.org>
Cc: linux-kernel@vger.kernel.org, linux-rt-users@vger.kernel.org,
Thomas Gleixner <tglx@linutronix.de>,
Daniel Wagner <daniel.wagner@bmw-carit.de>
Subject: Re: [RFC v1] sched/completion: convert completions to use simple wait queues
Date: Wed, 30 Mar 2016 17:17:29 +0200 [thread overview]
Message-ID: <56FBEE09.9080607@linutronix.de> (raw)
In-Reply-To: <20160330150747.GY3408@twins.programming.kicks-ass.net>
On 03/30/2016 05:07 PM, Peter Zijlstra wrote:
> On Wed, Mar 30, 2016 at 04:53:05PM +0200, Daniel Wagner wrote:
>> From: Daniel Wagner <daniel.wagner@bmw-carit.de>
>>
>> Completions have no long lasting callbacks and therefore do not need
>> the complex waitqueue variant. Use simple waitqueues which reduces
>> the contention on the waitqueue lock.
>
> Changelog really should have talk about the determinism thing. The last
> time you posted this the point was raised that we should wake the
> highest prio waiter in the defer case, you did not address this.
So we really want to go this road? I didn't find any numbers what the
highest count of queued sleepers was in Daniel's complete_all() testing.
As for the latest -RT I received only one report from Clark Williams
with something like 3 to 9 sleepers waked up during one complete_all()
and this happens in the resume code.
Based on this, deferring wake-ups from IRQ-context and a RB-tree (or
something like that for priority sorting) looks like a lot of complexity
and it does not look like we gain much.
> Also, you make no mention of the reduction of UINT_MAX to USHORT_MAX and
> the implications of that.
Wasn't this
|To avoid a size increase of struct completion, I spitted the done
|field into two half.
later he mentions that we can't have 2M sleepers anymore.
Sebastian
next prev parent reply other threads:[~2016-03-30 15:17 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-03-30 14:53 [RFC v1] Use swait in completion Daniel Wagner
2016-03-30 14:53 ` [RFC v1] sched/completion: convert completions to use simple wait queues Daniel Wagner
2016-03-30 15:07 ` Peter Zijlstra
2016-03-30 15:17 ` Sebastian Andrzej Siewior [this message]
2016-03-30 15:21 ` Peter Zijlstra
2016-03-30 15:29 ` 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=56FBEE09.9080607@linutronix.de \
--to=bigeasy@linutronix.de \
--cc=daniel.wagner@bmw-carit.de \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-rt-users@vger.kernel.org \
--cc=peterz@infradead.org \
--cc=tglx@linutronix.de \
--cc=wagi@monom.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.