linux-kernel - Re: [PATCH v2] sched/completion: convert completions to use simple wait queues

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] [thread-next>] [day] [month] [year] [list]

Date:	Fri, 29 Apr 2016 08:14:43 +0200
From:	Daniel Wagner <daniel.wagner@...-carit.de>
To:	<linux-kernel@...r.kernel.org>, <linux-rt-users@...r.kernel.org>
CC:	"Peter Zijlstra (Intel)" <peterz@...radead.org>,
	Thomas Gleixner <tglx@...utronix.de>,
	Sebastian Andrzej Siewior <bigeasy@...utronix.de>
Subject: Re: [PATCH v2] sched/completion: convert completions to use simple
 wait queues

On 04/28/2016 02:57 PM, Daniel Wagner wrote:
> Only one complete_all() user could been identified so far, which happens
> to be drivers/base/power/main.c. Several waiters appear when suspend
> to disk or mem is executed.

BTW, this is what I get when doing a 'echo "disk" > /sys/power/state' on
a 4 socket E5-4610 (Ivy Bridge EP) system.


swait_stat version 0.1
---------------------------------------------------------------------------------------------
                              class name     1 waiter    2 waiters    3 waiters   4+ waiters
---------------------------------------------------------------------------------------------
[...]
                             &x->wait#12           90           11            5            1
         [<ffffffff815dd462>] dpm_wait+0x32/0x40
                                                   20          [<ffffffff815de5d4>] __device_suspend+0x1b4/0x370
                                                    4          [<ffffffff815de1e4>] __device_suspend_late+0x74/0x210
                                                   22          [<ffffffff815ddf21>] __device_suspend_noirq+0x51/0x200
                                                    2          [<ffffffff815ddaf9>] device_resume_early+0x69/0x1b0
                                                   59          [<ffffffff815ddce0>] device_resume+0x50/0x1f0
[...]