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: <da91c950-51c0-4c71-855e-ae11898a97f5@gmail.com>
Date: Sat, 30 Sep 2023 19:31:34 +0700
From: Bagas Sanjaya <bagasdotme@...il.com>
To: John Ogness <john.ogness@...utronix.de>,
 Sergey Senozhatsky <senozhatsky@...omium.org>, Petr Mladek
 <pmladek@...e.com>, Todd Brandt <todd.e.brandt@...el.com>
Cc: Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
 Linux Regressions <regressions@...ts.linux.dev>,
 Linux Hardening <linux-hardening@...r.kernel.org>
Subject: Re: Fwd: Performance regression: resume_console takes 100ms longer in
 S2idle/S3 resume in v6.6-rc1

On 28/09/2023 07:17, Bagas Sanjaya wrote:
> Hi,
> 
> I notice a regression report on Bugzilla [1]. Quoting from it:
> 
>> Ever since 6.6.0-rc1 we've seen S3 and S2idle resume take 100ms longer because of resume_comsole. resume_console ordinarily takes only a few milliseconds, but now it's consistently 100ms. I've bisected the issue to this commit:
>>
>> commit 9e70a5e109a4a23367810de09be826c52d27ee2f
>> Author: John Ogness <john.ogness@...utronix.de>
>> Date:   Mon Jul 17 21:52:06 2023 +0206
>>
>>     printk: Add per-console suspended state
>>     
>>     Currently the global @console_suspended is used to determine if
>>     consoles are in a suspended state. Its primary purpose is to allow
>>     usage of the console_lock when suspended without causing console
>>     printing. It is synchronized by the console_lock.
>>     
>>     Rather than relying on the console_lock to determine suspended
>>     state, make it an official per-console state that is set within
>>     console->flags. This allows the state to be queried via SRCU.
>>     
>>     Remove @console_suspended. Console printing will still be avoided
>>     when suspended because console_is_usable() returns false when
>>     the new suspended flag is set for that console.
>>
>> We are seeing this on roughly 2/3 of our machines, both on test systems and production systems.
> 
> Then,
> 
>> The effect is most pronounced in the GigaByte z170x UD5. It goes from 300ms to 400ms because of an msleep 100 in the resume_console code. This might not seem like much but it's in series with everything else so it will always be there. Our goal is to keep both suspend and resume under 1 second if at all possible, so every bit counts.
> 
> See Bugzilla for the full thread and attached sleepgraph timelines
> (in html format).
> 
> Anyway, I'm adding this regression to be tracked by regzbot:
> 
> #regzbot introduced: 9e70a5e109a4a2 https://bugzilla.kernel.org/show_bug.cgi?id=217955
> #regzbot title: resume_console performance regression due to per-console suspended state
> 

#regzbot fix: printk: flush consoles before checking progress

-- 
An old man doll... just what I always wanted! - Clara


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ