linux-kernel - Re: Fwd: Performance regression: resume_console takes 100ms longer in S2idle/S3 resume in v6.6-rc1

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 for Android: free password hash cracker in your pocket

[<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