Sorry I don’t think often about GPU memory, VRAM.
On my system, it is at 1.3 GB.
There probably some margins of improvements.
Still that’s a lot less than my Firefox, 100 tabs uses 1,9 GB.
Sorry I don’t think often about GPU memory, VRAM.
On my system, it is at 1.3 GB.
There probably some margins of improvements.
Still that’s a lot less than my Firefox, 100 tabs uses 1,9 GB.
1.9 GB for 100 tabs is very good, actually it’s hard to believe. I can have just 2 or 3 tabs and exceed 3GB (but usually I’m using heavy sites like youtube)
I wanted to hop in here as well regarding a memory leak (skip to issue ”***” below)…
I’ve had systemd-cgtop running and have been watching session.slice climb to 2GB and saw both plasmashell and kwin_wayland being problematic. Even with all windows being closed.
System responsiveness would become horrible (so I edited the services’ drop-ins to exclude them from swapping out, which has been great, and increase their IOWeight).
I also thought I’d try setting memory.{high,max}, but that was a huge mistake (nearly no responsiveness when high), so I set them both back to max.
I’ve used heaptrack in the past with plasmashell’s x11 that really didn’t go anywhere, and I’ve since moved to wayland.
Previously, I think the issue may have stemmed from Intel’s IGP driver or something. There’s a topic open about that at freedesktop, but when I recently rebuilt my system, I no longer experience those effects (slab/Unevictable/SUnreclaim).
I’ll start that heaptrack is AMAZING, and I had no clue it was a KDE thing, so kudos!
But something I’d like to see (any feature-requests?) is for lldb to be an option to attach to a pid.
I thought I’d `ln -s`, but that doesn’t cut it (arguments not allowed or whatever). So I finally opted to install gdb.
I also was going to run (--replace) instead of attach for plasmashell and kwin_wayland, but there’s funny business with that, so I’m attached currently (forked off both).
I see that kwin_wayland isn’t as nice as its x11 counterpart when it comes to --replace. While it’d be great to not need such a feature, it’s especially helpful for scenarios like this.
***An issue I have with attaching to plasmashell is my bottom application panel is completely frozen. I don’t think it happened immediately, but as I was doing stuff (like enabling bluetooth to connect headset).
I can still switch windows and use that top-left corner trigger to show open-app overview.
I’m also seeing plasmashell using 75% CPU.
The backtrace for it is:
#0 0x00007ff32c2ba042 in ?? () from /usr/lib/libc.so.6
#1 0x00007ff32c2ae1ac in ?? () from /usr/lib/libc.so.6
#2 0x00007ff32c2fec12 in clock_nanosleep () from /usr/lib/libc.so.6
#3 0x00007ff32c30ac97 in nanosleep () from /usr/lib/libc.so.6
#4 0x00007ff2b92782d7 in heaptrack_malloc () from /usr/lib/heaptrack/libheaptrack_inject.so
#5 0x00007ff2b9278686 in ?? () from /usr/lib/heaptrack/libheaptrack_inject.so
#6 0x00007ff32c5ee6c5 in operator new (sz=31) at /usr/src/debug/gcc/gcc/libstdc++-v3/libsupc++/new_op.cc:50
#7 0x00007ff2b9272ab1 in ?? () from /usr/lib/heaptrack/libheaptrack_inject.so
#8 0x00007ff2b92732d9 in ?? () from /usr/lib/heaptrack/libheaptrack_inject.so
#9 0x00007ff32c384937 in dl_iterate_phdr () from /usr/lib/libc.so.6
#10 0x00007ff2b9277713 in ?? () from /usr/lib/heaptrack/libheaptrack_inject.so
#11 0x00007ff2dfd7dbae in ?? () from /usr/lib/libpipewire-0.3.so.0
#12 0x00007ff2dfd7e007 in ?? () from /usr/lib/libpipewire-0.3.so.0
#13 0x00007ff2dfd7e4a3 in pw_load_spa_handle () from /usr/lib/libpipewire-0.3.so.0
#14 0x00007ff2df335642 in ?? () from /usr/lib/pipewire-0.3/libpipewire-module-adapter.so
#15 0x00007ff2dfd98090 in pw_stream_connect () from /usr/lib/libpipewire-0.3.so.0
#16 0x00007ff2dfdf975b in PipeWireSourceStream::createStream(unsigned int, int) () from /usr/lib/libKPipeWire.so.6
#17 0x00007ff2dfdef6c4 in PipeWireSourceItem::refresh() () from /usr/lib/libKPipeWire.so.6
#18 0x00007ff2dfdef9f3 in PipeWireSourceItem::setNodeId(unsigned int) () from /usr/lib/libKPipeWire.so.6
#19 0x00007ff32dc72835 in ?? () from /usr/lib/libQt6Qml.so.6
#20 0x00007ff32dd4a18b in QQmlPropertyPrivate::write(QObject*, QQmlPropertyData const&, QVariant const&, QQmlRefPointer<QQmlContextData> const&, QFlags<QQmlPropertyData::WriteFlag>) () from /usr/lib/libQt6Qml.so.6
#21 0x00007ff32dc89025 in QQmlBinding::slowWrite(QQmlPropertyData const&, QQmlPropertyData const&, QV4::Value const&, bool, QFlags<QQmlPropertyData::WriteFlag>) () from /usr/lib/libQt6Qml.so.6
#22 0x00007ff32dc905a9 in ?? () from /usr/lib/libQt6Qml.so.6
#23 0x00007ff32dc8d1e5 in QQmlBinding::doUpdate(QQmlJavaScriptExpression::DeleteWatcher const&, QFlags<QQmlPropertyData::WriteFlag>, QV4::Scope&) () from /usr/lib/libQt6Qml.so.6
#24 0x00007ff32dc8bfcd in QQmlBinding::update(QFlags<QQmlPropertyData::WriteFlag>) () from /usr/lib/libQt6Qml.so.6
#25 0x00007ff32dd25398 in QQmlNotifier::emitNotify(QQmlNotifierEndpoint*, void**) () from /usr/lib/libQt6Qml.so.6
#26 0x00007ff32c9a6de2 in ?? () from /usr/lib/libQt6Core.so.6
#27 0x00007ff3057207df in ?? () from /usr/lib/libtaskmanager.so.6
#28 0x00007ff32c9a716f in ?? () from /usr/lib/libQt6Core.so.6
#29 0x00007ff30572036b in ?? () from /usr/lib/libtaskmanager.so.6
#30 0x00007ff32ba7eac6 in ?? () from /usr/lib/libffi.so.8
#31 0x00007ff32ba7b76b in ?? () from /usr/lib/libffi.so.8
#32 0x00007ff32ba7e06e in ffi_call () from /usr/lib/libffi.so.8
#33 0x00007ff32f26448d in ?? () from /usr/lib/libwayland-client.so.0
#34 0x00007ff32f2652e9 in ?? () from /usr/lib/libwayland-client.so.0
#35 0x00007ff32f2656f3 in wl_display_dispatch_queue_pending () from /usr/lib/libwayland-client.so.0
#36 0x00007ff32d836046 in QtWaylandClient::QWaylandDisplay::flushRequests() () from /usr/lib/libQt6WaylandClient.so.6
#37 0x00007ff32c994554 in QObject::event(QEvent*) () from /usr/lib/libQt6Core.so.6
#38 0x00007ff32e9b90a0 in QApplicationPrivate::notify_helper(QObject*, QEvent*) () from /usr/lib/libQt6Widgets.so.6
#39 0x00007ff32c93a6c8 in QCoreApplication::notifyInternal2(QObject*, QEvent*) () from /usr/lib/libQt6Core.so.6
#40 0x00007ff32c93aab2 in QCoreApplicationPrivate::sendPostedEvents(QObject*, int, QThreadData*) () from /usr/lib/libQt6Core.so.6
#41 0x00007ff32cc1db18 in ?? () from /usr/lib/libQt6Core.so.6
#42 0x00007ff32b174f4d in ?? () from /usr/lib/libglib-2.0.so.0
#43 0x00007ff32b176617 in ?? () from /usr/lib/libglib-2.0.so.0
#44 0x00007ff32b176825 in g_main_context_iteration () from /usr/lib/libglib-2.0.so.0
#45 0x00007ff32cc1a9d2 in QEventDispatcherGlib::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) () from /usr/lib/libQt6Core.so.6
#46 0x00007ff32c945a86 in QEventLoop::exec(QFlags<QEventLoop::ProcessEventsFlag>) () from /usr/lib/libQt6Core.so.6
#47 0x00007ff32c93f171 in QCoreApplication::exec() () from /usr/lib/libQt6Core.so.6
#48 0x000055b773c803e9 in ?? ()
#49 0x00007ff32c242675 in ?? () from /usr/lib/libc.so.6
#50 0x00007ff32c242729 in __libc_start_main () from /usr/lib/libc.so.6
#51 0x000055b773c80905 in ?? ()
I’m noticing the pipewire-related lines, which would align with what I was trying to do with bluetooth/sound.
plasma/kwin: 6.4.5
qt6: 6.10.0
pipewire: 1.4.9
Is there no edit feature here? I prefer to edit my posts/comments when I have new information, and no one has yet replied, to prevent any unnecessary spamming notifications to participants/subscribers.
In any case, while I had both plasmashell and kwin attached with heaptrack, I was nearly close to trying to free whatever was holding up plasmashell (eg restarting wireplumber/pipewire), but when I was switching windows and went to the “active window overview” (top-left corner), and pressed CTRL+spacebar to bring up krunner (which it doesn’t when in overview apparently), after the overview textbox received ko (going to be kodi), the entire GUI hung.
I was only able to “get out”(?) by multiple magic+sysrq+f (oom), when it finally kicked me out to SDDM.
When I logged back in to start it all over (with the intent of only tracking kwin this time), it ended up hanging again after I had 4 konsoles opened (1 with heaptrack for kwin forked), 2 browsers, jami, and kodi was in mid-process of loading when I went to the application panel to switch to a browser.
I again had to manually OOM to get freed. Mind you, there are no actual resource issues.
I’m back at it again now with basically the same thing opened (typing this now), and the main difference I’d say (considering pipewire’s role before) is I waited until I had everything open before linking my bluetooth.
…
OH THANK GOODNESS THIS SAVES DRAFTS!
I was in the middle of composing this, moved my mouse to the application panel, and BAM! Frozen again. My mouse wasn’t even over the bluetooth icon in the system panel.
I made sure to turn off my headset before logging back in so no bluetooth connection is made.
Everything is open again and I’ve moved my mouse to panel again multiple times and no problem.
No clue what(/if?) correlation there is with my connected headset and the panel freezing up when I’ve got heaptrack attached only to kwin.
Yeah, I’ve re-read what I wrote (giving time for any issue to come up/accumulate while I make text adjustments), moved my mouse around the panel, previewing windows, and such with no issues.
I’ll be leaving my bluetooth disconnected while heaptrack does its thing.
EDIT0: I see there is an edit pencil for this comment, but not my other? This is how I normally do it.
I guess the edit option only exists within an existing login session because it’s gone now.
Yes, that’s right, frozen again… So nothing to do with bluetooth.
Everything was working swimmingly (apart from heaptrack overhead, and without bluetooth), and I went to hover my mouse over kodi in the application panel to have a preview of the TV going while I was working on stuff, and before the preview popped up, the GUI froze again.
This time my hard drive was absolutely thrashing hard. I let it go for 10+ minutes before manually forcing multiple OOMs to get me back to SDDM.
It starts with being frozen, but sound from Kodi was still happening for <30s before it drops out too.
Then after a bit, I hear an indicator sound (error?), which I’m guessing correlates to OOM, though the first one was NOT instantiated by me. It’s a sound that also occurs when I manually OOM.
Journal:
Dec 11 13:27:28 computerName kernel: Purging GPU memory, 46 pages freed, 127914 pages still pinned, 0 pages left available.
Dec 11 13:27:28 computerName kernel: sysrq: Manual OOM execution
Dec 11 13:22:28 computerName tvheadend[1338631]: 2025-12-11 13:22:27.984 [ INFO] subscription: 001F: "epggrab" subscribing to mux "521.028MHz", weight: 4, adapter: "Auvitek AU8522 QAM/8VSB Frontend #0 : ATSC-T #0", network: "ATSC-T Network>
Dec 11 13:22:28 computerName tvheadend[1338631]: 2025-12-11 13:22:27.984 [ INFO] mpegts: 521.028MHz in ATSC-T Network - tuning on Auvitek AU8522 QAM/8VSB Frontend #0 : ATSC-T #0
Dec 11 13:22:27 computerName tvheadend[1338631]: subscription: 001F: "epggrab" subscribing to mux "521.028MHz", weight: 4, adapter: "Auvitek AU8522 QAM/8VSB Frontend #0 : ATSC-T #0", network: "ATSC-T Network", service: "Raw PID Subscription"
Dec 11 13:22:27 computerName tvheadend[1338631]: mpegts: 521.028MHz in ATSC-T Network - tuning on Auvitek AU8522 QAM/8VSB Frontend #0 : ATSC-T #0
Dec 11 13:22:26 computerName tvheadend[1338631]: subscription: 001E: "epggrab" unsubscribing
Dec 11 13:22:27 computerName tvheadend[1338631]: 2025-12-11 13:22:26.975 [ INFO] subscription: 001E: "epggrab" unsubscribing
Dec 11 13:22:27 computerName tvheadend[1338631]: 2025-12-11 13:22:26.975 [WARNING] epggrab: PSIP: ATSC Grabber - data completion timeout for 177.028MHz in ATSC-T Network
Dec 11 13:22:26 computerName tvheadend[1338631]: epggrab: PSIP: ATSC Grabber - data completion timeout for 177.028MHz in ATSC-T Network
Dec 11 13:22:03 computerName systemd-journald[856911]: Under memory pressure, flushing caches.
Dec 11 13:22:03 computerName kded6[1338833]: Failed to notify "Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or th>
Dec 11 13:22:01 computerName kded6[1338833]: Failed to notify "Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or th>
Dec 11 13:21:40 computerName systemd-journald[856911]: Under memory pressure, flushing caches.
Dec 11 13:21:40 computerName kernel: Memory cgroup out of memory: Killed process 1340794 (kodi.bin) total-vm:3144428kB, anon-rss:412632kB, file-rss:18448kB, shmem-rss:636kB, UID:1000 pgtables:1792kB oom_score_adj:200
Dec 11 13:21:40 computerName kernel: oom-kill:constraint=CONSTRAINT_MEMCG,nodemask=(null),cpuset=/,mems_allowed=0,oom_memcg=/user.slice/user-1000.slice/user@1000.service/app.slice/kodi-1340786.service,task_memcg=/user.slice/user-1000.slice/u>
Dec 11 13:21:40 computerName kernel: [1340794] 1000 1340794 786107 107929 103158 4612 159 1835008 0 200 kodi.bin
Dec 11 13:21:40 computerName kernel: [1340788] 1000 1340788 1960 921 64 857 0 61440 0 200 kodi
Dec 11 13:21:40 computerName kernel: [ pid ] uid tgid total_vm rss rss_anon rss_file rss_shmem pgtables_bytes swapents oom_score_adj name
Dec 11 13:21:40 computerName kernel: Tasks state (memory values in pages):
Dec 11 13:21:40 computerName kernel: numa_hint_faults 0
Dec 11 13:21:40 computerName kernel: numa_pte_updates 0
Dec 11 13:21:40 computerName kernel: numa_pages_migrated 0
Dec 11 13:21:40 computerName kernel: thp_swpout_fallback 0
Dec 11 13:21:40 computerName kernel: thp_swpout 0
Dec 11 13:21:40 computerName kernel: thp_collapse_alloc 0
Dec 11 13:21:40 computerName kernel: thp_fault_alloc 129519
Dec 11 13:21:40 computerName kernel: zswpwb 0
Dec 11 13:21:40 computerName kernel: zswpout 0
Dec 11 13:21:40 computerName kernel: zswpin 0
Dec 11 13:21:40 computerName kernel: swpout_zero 0
Dec 11 13:21:40 computerName kernel: swpin_zero 0
Dec 11 13:21:40 computerName kernel: pglazyfreed 0
Dec 11 13:21:40 computerName kernel: pglazyfree 0
Dec 11 13:21:40 computerName kernel: pgdeactivate 0
Dec 11 13:21:40 computerName kernel: pgactivate 43
Dec 11 13:21:40 computerName kernel: pgrefill 148
Dec 11 13:21:40 computerName kernel: pgmajfault 111
Dec 11 13:21:40 computerName kernel: pgfault 625814
Dec 11 13:21:40 computerName kernel: pgsteal_proactive 0
Dec 11 13:21:40 computerName kernel: pgsteal_khugepaged 0
Dec 11 13:21:40 computerName kernel: pgsteal_direct 2961
Dec 11 13:21:40 computerName kernel: pgsteal_kswapd 70
Dec 11 13:21:40 computerName kernel: pgscan_proactive 0
Dec 11 13:21:40 computerName kernel: pgscan_khugepaged 0
Dec 11 13:21:40 computerName kernel: pgscan_direct 3004
Dec 11 13:21:40 computerName kernel: pgscan_kswapd 70
Dec 11 13:21:40 computerName kernel: pswpout 0
Dec 11 13:21:40 computerName kernel: pswpin 0
Dec 11 13:21:40 computerName kernel: pgsteal 3031
Dec 11 13:21:40 computerName kernel: pgscan 3074
Dec 11 13:21:40 computerName kernel: pgpromote_success 0
Dec 11 13:21:40 computerName kernel: pgdemote_proactive 0
Dec 11 13:21:40 computerName kernel: pgdemote_khugepaged 0
Dec 11 13:21:40 computerName kernel: pgdemote_direct 0
Dec 11 13:21:40 computerName kernel: pgdemote_kswapd 0
Dec 11 13:21:40 computerName kernel: workingset_nodereclaim 0
Dec 11 13:21:40 computerName kernel: workingset_restore_file 0
Dec 11 13:21:40 computerName kernel: workingset_restore_anon 0
Dec 11 13:21:40 computerName kernel: workingset_activate_file 0
Dec 11 13:21:40 computerName kernel: workingset_activate_anon 0
Dec 11 13:21:40 computerName kernel: workingset_refault_file 19
Dec 11 13:21:40 computerName kernel: workingset_refault_anon 0
Dec 11 13:21:40 computerName kernel: slab 4498840
Dec 11 13:21:40 computerName kernel: slab_unreclaimable 3654424
Dec 11 13:21:40 computerName kernel: slab_reclaimable 844416
Dec 11 13:21:40 computerName kernel: unevictable 92663808
Dec 11 13:21:40 computerName kernel: active_file 0
Dec 11 13:21:40 computerName kernel: inactive_file 0
Dec 11 13:21:40 computerName kernel: active_anon 117710848
Dec 11 13:21:40 computerName kernel: inactive_anon 306798592
Dec 11 13:21:40 computerName kernel: shmem_thp 0
Dec 11 13:21:40 computerName kernel: file_thp 0
Dec 11 13:21:40 computerName kernel: anon_thp 16777216
Dec 11 13:21:40 computerName kernel: swapcached 0
Dec 11 13:21:40 computerName kernel: file_writeback 0
Dec 11 13:21:40 computerName kernel: file_dirty 0
Dec 11 13:21:40 computerName kernel: file_mapped 851968
Dec 11 13:21:40 computerName kernel: zswapped 0
Dec 11 13:21:40 computerName kernel: zswap 0
Dec 11 13:21:40 computerName kernel: shmem 94019584
Dec 11 13:21:40 computerName kernel: vmalloc 4096
Dec 11 13:21:40 computerName kernel: sock 40960
Dec 11 13:21:40 computerName kernel: percpu 408
Dec 11 13:21:40 computerName kernel: sec_pagetables 0
Dec 11 13:21:40 computerName kernel: pagetables 0
Dec 11 13:21:40 computerName kernel: kernel_stack 524288
Dec 11 13:21:40 computerName kernel: kernel 6950912
Dec 11 13:21:40 computerName kernel: file 94019584
Dec 11 13:21:40 computerName kernel: anon 423182336
Dec 11 13:21:40 computerName kernel: Memory cgroup stats for /user.slice/user-1000.slice/user@1000.service/app.slice/kodi-1340786.service:
Dec 11 13:21:40 computerName kernel: swap: usage 0kB, limit 9007199254740988kB, failcnt 0
Dec 11 13:21:40 computerName kernel: memory: usage 512000kB, limit 512000kB, failcnt 203
Dec 11 13:21:40 computerName kernel: </TASK>
Dec 11 13:21:40 computerName kernel: R13: 00007ffab403e6f0 R14: 00007ffab403e6f0 R15: 00007ffaf0743260
Dec 11 13:21:40 computerName kernel: R10: 0000000000000022 R11: 0000000000000246 R12: 00007ffa76879350
Dec 11 13:21:40 computerName kernel: RBP: 00007ffabe7fb4b0 R08: 00007ffaa4246010 R09: 0000000000000000
Dec 11 13:21:40 computerName kernel: RDX: 000000000002dc7a RSI: 00007ffaa473c084 RDI: 00007ffaa4266000
Dec 11 13:21:40 computerName kernel: RAX: 00007ffaa4246010 RBX: 00007ffae8021b40 RCX: 000000000000dc8a
Dec 11 13:21:40 computerName kernel: RSP: 002b:00007ffabe7fb438 EFLAGS: 00010202
Dec 11 13:21:40 computerName kernel: Code: 5e 22 0a 00 01 74 9c 83 f9 c0 0f 87 7e fe ff ff c5 fe 6f 4e 20 48 29 fe 48 83 c7 3f 49 8d 0c 10 48 83 e7 c0 48 01 fe 48 29 f9 <f3> a4 c4 c1 7e 7f 00 c4 c1 7e 7f 48 20 c5 f8 77 c3 0f 1f 84 00 00
Dec 11 13:21:40 computerName kernel: RIP: 0033:0x7ffb2d44a087
Dec 11 13:21:40 computerName kernel: asm_exc_page_fault+0x26/0x30
Dec 11 13:21:40 computerName kernel: exc_page_fault+0x75/0xe0
Dec 11 13:21:40 computerName kernel: do_user_addr_fault+0x271/0x680
Dec 11 13:21:40 computerName kernel: ? syscall_exit_work+0xcc/0x150
Dec 11 13:21:40 computerName kernel: handle_mm_fault+0x76c/0x11d0
Dec 11 13:21:40 computerName kernel: ? ___pte_offset_map+0x1d/0x100
Dec 11 13:21:40 computerName kernel: do_pte_missing+0x8f0/0xec0
Dec 11 13:21:40 computerName kernel: __mem_cgroup_charge+0x42/0xc0
Dec 11 13:21:40 computerName kernel: try_charge_memcg+0x4a9/0x6c0
Dec 11 13:21:40 computerName kernel: out_of_memory+0x3c3/0x570
Dec 11 13:21:40 computerName kernel: oom_kill_process+0x1d0/0x230
Dec 11 13:21:40 computerName kernel: dump_header+0x43/0x120
Dec 11 13:21:35 computerName systemd[1338622]: kodi-1340786.service: Consumed 6min 59.920s CPU time, 500.3M memory peak.
Dec 11 13:21:39 computerName kernel: dump_stack_lvl+0x5e/0x80
Dec 11 13:21:35 computerName systemd[1338622]: kodi-1340786.service: Failed with result 'oom-kill'.
Dec 11 13:21:39 computerName kernel: <TASK>
Dec 11 13:21:35 computerName systemd[1338622]: kodi-1340786.service: Main process exited, code=exited, status=137/n/a
Dec 11 13:21:39 computerName kernel: Call Trace:
Dec 11 13:21:35 computerName systemd[1338622]: kodi-1340786.service: A process of this unit has been killed by the OOM killer.
Dec 11 13:21:35 computerName tvheadend[1338631]: htsp: 127.0.0.1 [ kodi | Kodi Media Center ]: Disconnected
Dec 11 13:21:38 computerName kernel: Hardware name: To Be Filled By O.E.M. To Be Filled By O.E.M./H97M-ITX/ac, BIOS P2.00 03/07/2018
Dec 11 13:21:35 computerName systemd[1]: user@1000.service: A process of this unit has been killed by the OOM killer.
Dec 11 13:21:38 computerName tvheadend[1338631]: 2025-12-11 13:21:35.318 [ INFO] htsp: 127.0.0.1 [ kodi | Kodi Media Center ]: Disconnected
Dec 11 13:21:38 computerName tvheadend[1338631]: 2025-12-11 13:21:35.309 [ INFO] htsp: 127.0.0.1 [ kodi | Kodi Media Center ]: Write error -- Broken pipe
Dec 11 13:21:35 computerName tvheadend[1338631]: htsp: 127.0.0.1 [ kodi | Kodi Media Center ]: Write error -- Broken pipe
Dec 11 13:21:38 computerName kernel: CPU: 2 UID: 1000 PID: 1340832 Comm: JobWorker Not tainted 6.18.0-rc2 #3 PREEMPT(full) 2b8f1344adaeb73b536791c8fe0b517836968db6
Dec 11 13:21:37 computerName kodi[1340788]: /usr/bin/kodi: line 215: 1340794 Killed ${KODI_BINARY} ${ENV_ARGS} $SAVED_ARGS
Dec 11 13:21:35 computerName kernel: JobWorker invoked oom-killer: gfp_mask=0xcc0(GFP_KERNEL), order=0, oom_score_adj=200
Dec 11 13:16:48 computerName google-chrome-stable[1339608]: [1339602:1339630:1211/131648.182396:ERROR:google_apis/gcm/engine/registration_request.cc:291] Registration response error message: DEPRECATED_ENDPOINT
Dec 11 13:15:22 computerName kwin_wayland[1338720]: The main thread was hanging temporarily!
Dec 11 13:14:30 computerName kwin_wayland[1338720]: Libinput: client bug: timer button-debounce-debounce-event4: scheduled expiry is in the past (-58ms), your system is too slow
Dec 11 13:14:30 computerName kwin_wayland[1338720]: Libinput: client bug: timer button-debounce-debounce-event4: scheduled expiry is in the past (-85ms), your system is too slow
Dec 11 13:13:32 computerName chrome[1344235]: [1344235:1344297:1211/131332.612265:INFO:chrome/browser/extensions/extension_garbage_collector.cc:184] Garbage collection for extensions on file thread is complete.
I’m quite certain the kodi oom was due to my –property MemoryMax=500M for the process, and probably accumulated because everything was in a frozen state and it was still trying to play. It hasn’t been something I needed for a long time (years?).
I’ll see if I can replicate the thrashing with iotop batch writing to a file so I can see who the offender was. Again, this would be a good example of where the edit option would be nice so I can update this comment with the result without participants getting an unnecessary update notification for something so minor.
So I won’t be able to provide a heaptrack of anything useful until whatever this is going on gets resolved.
You can kill kwin_wayland, it is handled for at least Qt/KDE applications.
We have the kwin_wayland_wrapper, that will handle the transition to a new kwin_wayland instance.
I can also recommend you hotspot.
I’ve tried to troubleshoot memory issues in kwin_wayland and plasmashell recently, but when I attach heaptrack to the pid to check it out, my desktop goes to 1 frame per 10 seconds, so no bueno since 6.4. I could do this in 6.3, which helped me before. Sadly I can’t really debug it now, probably you either by normal means but curious either way if better results.
I get kwin_wayland using 3gb of ram, plasmashell around 2gb, this is a 11520x2160 display arrangement, it seems pretty normal for my usage, why I have 128gb in this thing. Probably no good for the average windoze/mac convert with 8/16gb systems trying to get their swerve on with linux, but relative to your display size for sure.
Before with the slideshow wallpaper I’d see it use 100 gb of ram, so better, but still a bit chonky even barring catastrophic bugs like that.