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