| Summary: | Screen freezes briefly when starting Element | ||
|---|---|---|---|
| Product: | [Plasma] kwin | Reporter: | Jakob Petsovits <jpetso> |
| Component: | wayland-generic | Assignee: | KWin default assignee <kwin-bugs-null> |
| Status: | REPORTED --- | ||
| Severity: | normal | CC: | nate, xaver.hugl |
| Priority: | NOR | ||
| Version First Reported In: | git master | ||
| Target Milestone: | --- | ||
| Platform: | Other | ||
| OS: | Linux | ||
| See Also: | https://bugs.kde.org/show_bug.cgi?id=499426 | ||
| Latest Commit: | Version Fixed In: | ||
| Sentry Crash Report: | |||
| Attachments: |
Stuttering kwin_wayland trace 1 (default sample rate, no initial screen activity)
Stuttering kwin_wayland trace 2 (5700 Hz sample rate, no initial screen activity) Stuttering kwin_wayland trace 3 (5700 Hz sample rate, always moving mouse pointer) Stuttering kwin_wayland trace 4 (5700 Hz sample rate, system-wide) |
||
|
Description
Jakob Petsovits
2025-02-06 20:19:49 UTC
I see no stutter or hang when opening element. If you can ssh in from a second device, could you get the backtrace from where KWin is stuck (if it is stuck in any specific place)? Created attachment 178673 [details] Stuttering kwin_wayland trace 1 (default sample rate, no initial screen activity) So I haven't set up my sshd yet and wasn't confident that I'd hit the enter key at the right time for the right breakpoint. I decided to learn about perf instead. Here are a few for the kwin_wayland process, captured with perf record and converted to Firefox Profiler format with: > element-desktop & > sudo perf record -g -p <pid of kwin_wayland> > # click on Konsole window to refocus it, then Ctrl+C to stop recording > sudo chown kpetso:kpetso perf.data > perf script report gecko > # open https://profiler.firefox.com/ to load gecko_profile.json This first profile was fairly well timed, the stutter occurring shortly after the perf invocation. I didn't move the mouse or have animations on at first, so there's no activity on the kwin_wayland thread before the block. Once I figured out how to get a good view into the profile (i.e. with Firefox), it's pretty obvious what's going on. My other profiles also confirm this. Through some timer signal/slot, the main thread calls GlobalShortcutsRegistry::refreshServices(), which in turn asks for a KService::serviceByStorageId(), which calls KSycoca::ensureCacheValid() and for some reason the cache has to be recreated. Being KSycoca, that takes a little while and until it's done, it blocks on a lockfile. This blocking is my stutter. Created attachment 178674 [details]
Stuttering kwin_wayland trace 2 (5700 Hz sample rate, no initial screen activity)
Here's a similar profile, except recorded with -F 5700, which is the maximum it lets me do.
Created attachment 178675 [details]
Stuttering kwin_wayland trace 3 (5700 Hz sample rate, always moving mouse pointer)
For this one, I thought wouldn't it be nice if I kept moving the mouse all throughout so the pause is clearly visible? So this profile is perhaps the clearest insight. Toward the end there are brief input breaks prior to stopping my perf invocation, but the big pause at the beginning is extremely visible and with just the same stacktrace.
I could probably take another profile that shows system-wide loads, but this is what I've got right now, it looks actionable enough to act on. Let me know if you need anything else in particular.
Created attachment 178678 [details]
Stuttering kwin_wayland trace 4 (5700 Hz sample rate, system-wide)
Alright, I took another few profiles system-wide, showing all processes. Uploading the clearest one. In this profile, ksycoca6 shows up prominently (twice!) while kwin_wayland only gets more samples later in the recording. I'm not quite sure why it doesn't continue working sooner after ksycoca6 is finished, but once it does, it's still finishing up GlobalShortcutsRegistry::refreshServices().
Interestingly, plasmashell is also doing a bunch of work shortly afterwards, focused on KAStatsFavoritesModel and AppEntry::reload(). That's probably related to my Element icon in the panel's favorites list, so it can temporarily remove it and make an task entry (traditional Icons-and-Text panel). In another system-wide trace, I saw plasmashell write the new sycoca instead of a dedicated kbuildsycoca6 process. I guess the KBuildSycoca class isn't picky which process does the work.
|