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 <[email protected]>
> 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
Thanks.
[1]: https://bugzilla.kernel.org/show_bug.cgi?id=217955
--
An old man doll... just what I always wanted! - Clara
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 <[email protected]>
>> 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