linux-kernel - Re: [RFC v0] Use swait in completion

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <56FCC040.7080504@monom.org>
Date:	Thu, 31 Mar 2016 08:14:24 +0200
From:	Daniel Wagner <wagi@...om.org>
To:	Steven Rostedt <rostedt@...dmis.org>,
	Sebastian Andrzej Siewior <bigeasy@...utronix.de>
Cc:	Josh Cartwright <joshc@...com>, linux-kernel@...r.kernel.org,
	linux-rt-users@...r.kernel.org,
	"Peter Zijlstra (Intel)" <peterz@...radead.org>,
	Thomas Gleixner <tglx@...utronix.de>,
	Daniel Wagner <daniel.wagner@...-carit.de>
Subject: Re: [RFC v0] Use swait in completion

On 03/28/2016 08:57 PM, Steven Rostedt wrote:
> On Wed, 9 Mar 2016 13:24:23 +0100
> Sebastian Andrzej Siewior <bigeasy@...utronix.de> wrote:
> 
>> * Josh Cartwright | 2016-03-08 12:26:56 [-0600]:
>>
>>> Is it really just about latency?  Does this deferral not lead to an
>>> inversion in the case where the single woken task isn't the highest
>>> priority waiter on the completion (and doesn't run due to a
>>> middle-priority thing spinning)?  
>>
>> This would be case, yes. Not only with deferral. Say you have two
>> waters: 1st one is MID-prio and the second is HI-prio. Currently after
>> the wakeup of the MID-prio waiter you get preempted. Waking all of them
>> at once would put the second waiter first on the CPU.
>> Samething without the deferral flag.
>>
>>> In order for this to work, it seems like the chosen waiter would need to
>>> inherit the highest priority of all waiters (which AFAICT isn't
>>> happening).  
>>
>> sorting the waiters by priority? This will be fun. This is only done for
>> the rtmutex waiters.
>>
> 
> Hmm, perhaps we should use an rbtree to sort simple waiters by
> priority :-)
> 
> Probably wont make them simple anymore.

I am going through the users of complete_all(). So far I couldn't
identify any user with more than one waiter. That doesn't mean they
don't exist (maybe overlooked).

The -rt version of this patch contains a WARN_ON() in complete_all() if
there are more than one waiter. During resume some warnings are printed.
Let's see if there are more reports showing up.

If the common use case is one waiter and only in slow paths we see
several waiters I would like to avoid to adding fairness and increase
the complexity.

cheers,
daniel