I've noticed that when doing heavy disk-io KWin will often lag when starting an effect as if it has to do some disk-io. I'm not using swap. I don't know any of KWin internals but it seems to me that doing disk-io should not be necessary when doing e.g. present windows. If it is indeed disk-io doing this, then the potential of a smoother KWin is high by eliminating it. KSysguard shows kwin as having read 1,7 GB (???). I don't know how to read those numbers, but I'm attaching a screenshot. Thanks for a great window manager and compositor. Reproducible: Sometimes
Created attachment 78769 [details] Ksysguard screenshot of KWin IO
Nvidia GPU? KWIN_NVIDIA_HACK=0 __GL_YIELD="USLEEP" kwin --replace &
No. Intel. My specs: http://computers.pricegrabber.co.uk/laptop/Lenovo-T410s-Notebook-PC/m780221798.html#tab=details
I'm using ubuntu packages (just for info)
OpenGL vendor string: Intel Open Source Technology Center OpenGL renderer string: Mesa DRI Intel(R) Ironlake Mobile OpenGL version string: 2.1 Mesa 9.0.3 OpenGL shading language version string: 1.20 Driver: Intel GPU class: i965 OpenGL version: 2.1 GLSL version: 1.20 Mesa version: 9.0.3 X server version: 1.13 Linux kernel version: 3.5 Direct rendering: yes Requires strict binding: no GLSL shaders: yes Texture NPOT support: yes Virtual Machine: no
can please do some investigations to ensure that it's not the I/O going on elsewhere which just slows down the complete system. E.g. verify with iotop whether KWin is doing IO at all and if possible figure out which files KWin is reading. Effects like Present Windows should not use anything except Plasma Theme elements and icons. All those should be memory-mapped, though.
I kinda misread the OP, sorry: "I've noticed that when doing heavy disk-io KWin will often lag when starting an effect as if it has to do some disk-io." -> plasma theme cache, I bet anyones arms on that ;-) @Pascal: - does it happen w/ present windows when turning of icons and the close button? (in general explain more detailed what "lags") - where do you keep "/var/tmp/kdecache-`whoami`"? - does it also happen w/ XRender compositing? - does it also happen for undecorated windows? (alt+f3 / more actions) -- OT ---- ------------------------- The KWin I/O is either - GL - X11 - plasma theme ("present windows" plasma elements) ie. SHM -> likely nothing we can really avoid (the nvidia call prevents from the nvidia blob taking too much time slices, leaving nothing for actual KWin in that situations - at least here. This helps if there's other I/O load blocking KWin)
Just did iotop -p $KWinPID For each effect, the first time I do it, it reads and writes in KWin process. The worst lag I've experienced is KWin not doing what I asked before 2-3 seconds. I don't remember if actual effect is laggy. pascal@T410s:~$ lsof |grep 2805 | grep /var/tmp/kdecache kwin 2805 pascal mem REG 8,1 84377704 797427 /var/tmp/kdecache-pascal/plasma_theme_default.kcache kwin 2805 pascal mem REG 8,1 2088566 784165 /var/tmp/kdecache-pascal/ksycoca4 kwin 2805 pascal mem REG 8,1 10547304 788312 /var/tmp/kdecache-pascal/icon-cache.kcache kwin 2805 pascal 18r REG 8,1 2088566 784165 /var/tmp/kdecache-pascal/ksycoca4 QProcessM 2805 2808 pascal mem REG 8,1 84377704 797427 /var/tmp/kdecache-pascal/plasma_theme_default.kcache QProcessM 2805 2808 pascal mem REG 8,1 2088566 784165 /var/tmp/kdecache-pascal/ksycoca4 QProcessM 2805 2808 pascal mem REG 8,1 10547304 788312 /var/tmp/kdecache-pascal/icon-cache.kcache QProcessM 2805 2808 pascal 18r REG 8,1 2088566 784165 /var/tmp/kdecache-pascal/ksycoca4 kwin 2805 2812 pascal mem REG 8,1 84377704 797427 /var/tmp/kdecache-pascal/plasma_theme_default.kcache kwin 2805 2812 pascal mem REG 8,1 2088566 784165 /var/tmp/kdecache-pascal/ksycoca4 kwin 2805 2812 pascal mem REG 8,1 10547304 788312 /var/tmp/kdecache-pascal/icon-cache.kcache kwin 2805 2812 pascal 18r REG 8,1 2088566 784165 /var/tmp/kdecache-pascal/ksycoca4 QInotifyF 2805 4380 pascal mem REG 8,1 84377704 797427 /var/tmp/kdecache-pascal/plasma_theme_default.kcache QInotifyF 2805 4380 pascal mem REG 8,1 2088566 784165 /var/tmp/kdecache-pascal/ksycoca4 QInotifyF 2805 4380 pascal mem REG 8,1 10547304 788312 /var/tmp/kdecache-pascal/icon-cache.kcache QInotifyF 2805 4380 pascal 18r REG 8,1 2088566 784165 /var/tmp/kdecache-pascal/ksycoca4 - where do you keep "/var/tmp/kdecache-`whoami`"? pascal@T410s:~$ df -h /var/tmp/kdecache-pascal Filesystem Size Used Avail Use% Mounted on /dev/sda1 15G 9.5G 4.1G 71% /
.... "what kind of filesystem is /dev/sda1?" also see the question about deactivating close buttons & icons for "present windows"
.... "what kind of filesystem is /dev/sda1?" ext4 - does it happen w/ present windows when turning of icons and the close button? (in general explain more detailed what "lags") After having done kwin --replace and turned off icons and close button in present windows effect it still does IO on disk the first time. In ksysguard I notice that KWin is constantly ticking away with read and especially write syscalls (hover mouse over IO Read column). That isn't registered on iotop, so probably isn't disk-io.
you can ignore any non disk i/o - that's x11 and likely gl kcmshell4 kwincompositing, 2nd tab - scale method -> smooth? (accurate invokes shaders) in general attach the output of "qdbus org.kde.kwin /KWin supportInformation"
Created attachment 78793 [details] KWin support info
Scale method is set to accurate
> kcmshell4 kwincompositing, 2nd tab - scale method -> smooth? (accurate > invokes shaders) That should be just GL and the cache textures which should just be memory.
(In reply to comment #13) > Scale method is set to accurate Please try setting it to smooth. @Martin: yes, but but eg. nvidia writes shader compiling results to disk (by default)
I'm using Intel. I tried setting it to smooth and did kwin --replace. It still does disk io.
-> strace kwin, check *what* i/o happens in that occasion.
I tried a couple of times now, but it either returns "millions of lines" of output or it freezes my X. Tried: 1 strace kwin --replace 2 killall kwin; sleep 2; strace kwin; How should I do it?
strace kwin --replace 2>&1 | grep -E '^open|^lstat|^access' eventually strace kwin --replace 2>&1 | grep -E '^open|^lstat|^access' > io.strace and io.strace can maybe be in tmpfs - disadvantage is that a) you cannot see the output "while acting" b) if you run OOM (in the tmpfs case) the kernel will crash (random things) since you can't swap
better run it from a tty - that should prevent X from freezing
ideally from a second machine + ssh (so that you can see the output and the effect at the same time nevertheless) - but only printing that I/O should not cause recursions.
Created attachment 78798 [details] strace from kwin --replace and present windows I went to a tty and ran the following script, back to X, did present windows, back to tty and CTRL+C #!/bin/bash export DISPLAY=:0 strace kwin --replace 2>&1 | grep -E '^open|^lstat|^access' > io.strace
it loads the plasma theme ... because of those settings: showIcons: true doNotCloseWindows: false and contradicting comment #10
I consider it useful features, so I reenabled it after having done that test. Anyway the IO also happens with the other effects so I don't see those settings should matter.
Please disable them to un-pollute the strace? That I/O is really no surprise.
Created attachment 78807 [details] strace2 from kwin --replace and present windows
Still ends in plasma theme loading. Eventually for the windowfilter (when you'd start typing) - but that should only be loaded when actually starting to type. If you've enough memory, move /var/tmp/kdecache-seth/plasma_theme_* to some tmpfs disk (at least the currently used one, eg. using symlinks) and see what happens.
have you tried moving the theme to memory and did that have any impact?
for bug #320354 this ultimately leads to a (very likely OOM) crash, so there really seems some memory issue. ----- Application: kwin (4.10.2) KDE Platform Version: 4.10.2 (Compiled from sources) Qt Version: 4.8.4 Operating System: Linux 3.8.0-22-generic i686 Distribution: Ubuntu 13.04 -- Information about the crash: - What I was doing when the application crashed: I was just copying a large number of files to an external hard drive to save them. The crash can be reproduced every time. -- Backtrace: Application: KWin (kwin), signal: Segmentation fault Using host libthread_db library "/lib/i386-linux-gnu/libthread_db.so.1". [Current thread is 1 (Thread 0xb11ef740 (LWP 2603))] Thread 3 (Thread 0xae00cb40 (LWP 2609)): #0 0xb77d2424 in __kernel_vsyscall () #1 0xb225984b in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/i386-linux-gnu/libpthread.so.0 #2 0xb75a5d7c in pthread_cond_wait () from /lib/i386-linux-gnu/libc.so.6 #3 0xb66c00ed in ?? () from /usr/lib/i386-linux-gnu/libQtScript.so.4 #4 0xb66c011f in ?? () from /usr/lib/i386-linux-gnu/libQtScript.so.4 #5 0xb2255d78 in start_thread () from /lib/i386-linux-gnu/libpthread.so.0 #6 0xb75983de in clone () from /lib/i386-linux-gnu/libc.so.6 Thread 2 (Thread 0xad1e2b40 (LWP 2610)): #0 0xb600276a in QEventDispatcherUNIXPrivate::processThreadWakeUp (this=0xac800498, nsel=-1) at kernel/qeventdispatcher_unix.cpp:321 #1 0xb60043ce in QEventDispatcherUNIXPrivate::doSelect (this=this@entry=0xac800498, flags=..., timeout=0x0) at kernel/qeventdispatcher_unix.cpp:276 #2 0xb6004a13 in QEventDispatcherUNIX::processEvents (this=0xac800488, flags=...) at kernel/qeventdispatcher_unix.cpp:937 #3 0xb5fce3ec in QEventLoop::processEvents (this=this@entry=0xad1e2228, flags=...) at kernel/qeventloop.cpp:149 #4 0xb5fce6e1 in QEventLoop::exec (this=this@entry=0xad1e2228, flags=...) at kernel/qeventloop.cpp:204 #5 0xb5eb9fec in QThread::exec (this=this@entry=0x8702138) at thread/qthread.cpp:542 #6 0xb5fadf2d in QInotifyFileSystemWatcherEngine::run (this=0x8702138) at io/qfilesystemwatcher_inotify.cpp:256 #7 0xb5ebcb18 in QThreadPrivate::start (arg=0x8702138) at thread/qthread_unix.cpp:338 #8 0xb2255d78 in start_thread () from /lib/i386-linux-gnu/libpthread.so.0 #9 0xb75983de in clone () from /lib/i386-linux-gnu/libc.so.6 Thread 1 (Thread 0xb11ef740 (LWP 2603)): [KCrash Handler] #7 0xa6d15371 in r600_context_bo_reloc (usage=RADEON_USAGE_READ, ring=0x88de590, ctx=0x88de448, rbo=<optimized out>) at r600_pipe.h:888 #8 r600_emit_constant_buffers (rctx=rctx@entry=0x88de448, state=state@entry=0x88de9f0, buffer_id_base=buffer_id_base@entry=160, reg_alu_constbuf_size=reg_alu_constbuf_size@entry=164224, reg_alu_const_cache=reg_alu_const_cache@entry=166272) at r600_state.c:2050 #9 0xa6d15559 in r600_emit_vs_constant_buffers (rctx=0x88de448, atom=0x88de9f0) at r600_state.c:2074 #10 0xa6d28bec in r600_emit_atom (atom=0x88de9f0, rctx=0x88de448) at r600_pipe.h:573 #11 r600_draw_vbo (ctx=0x88de448, dinfo=0xbfda76f0) at r600_state_common.c:1390 #12 0xa65e605a in u_vbuf_draw_vbo (mgr=0x8978f40, info=info@entry=0xbfda76f0) at util/u_vbuf.c:1143 #13 0xa65751aa in cso_draw_vbo (cso=0x8978788, info=info@entry=0xbfda76f0) at cso_cache/cso_context.c:1344 #14 0xa668f1ba in st_draw_vbo (ctx=0x8929f88, prims=0xbfda7770, nr_prims=1, ib=0x0, index_bounds_valid=1 '\001', min_index=0, max_index=5, tfb_vertcount=0x0) at ../../../../../src/mesa/state_tracker/st_draw.c:287 #15 0xa6a6d4f2 in vbo_draw_arrays (ctx=ctx@entry=0x8929f88, mode=mode@entry=4, start=start@entry=0, count=count@entry=6, numInstances=numInstances@entry=1, baseInstance=baseInstance@entry=0) at ../../../../../src/mesa/vbo/vbo_exec_array.c:619 #16 0xa6a6d5dd in vbo_exec_DrawArrays (mode=4, start=0, count=6) at ../../../../../src/mesa/vbo/vbo_exec_array.c:649 #17 0xb64efc85 in KWin::GLVertexBufferPrivate::corePainting (this=0x896ea90, region=..., primitiveMode=4, hardwareClipping=false) at ../../../kwin/libkwineffects/kwinglutils.cpp:1254 #18 0xb64eff4d in KWin::GLVertexBuffer::render (this=this@entry=0x896b0f8, region=..., primitiveMode=primitiveMode@entry=4, hardwareClipping=hardwareClipping@entry=false) at ../../../kwin/libkwineffects/kwinglutils.cpp:1363 #19 0xb64f0002 in KWin::GLVertexBuffer::render (this=this@entry=0x896b0f8, primitiveMode=primitiveMode@entry=4) at ../../../kwin/libkwineffects/kwinglutils.cpp:1355 #20 0xa45b2772 in KWin::BlurEffect::drawRegion (this=this@entry=0x8adc6b8, region=...) at ../../../kwin/effects/blur/blur.cpp:254 #21 0xa45b3816 in KWin::BlurEffect::doCachedBlur (this=this@entry=0x8adc6b8, w=w@entry=0x8c8e128, region=..., opacity=1) at ../../../kwin/effects/blur/blur.cpp:669 #22 0xa45b4c1e in KWin::BlurEffect::drawWindow (this=0x8adc6b8, w=0x8c8e128, mask=10, region=..., data=...) at ../../../kwin/effects/blur/blur.cpp:411 #23 0xb77504a3 in KWin::EffectsHandlerImpl::drawWindow (this=0x8a98780, w=w@entry=0x8c8e128, mask=mask@entry=10, region=..., data=...) at ../../kwin/effects.cpp:315 #24 0xb772aff2 in KWin::Scene::finalPaintWindow (this=0x896eac8, w=w@entry=0x8c8e128, mask=mask@entry=10, region=..., data=...) at ../../kwin/scene.cpp:449 #25 0xb7750783 in KWin::EffectsHandlerImpl::paintWindow (this=0x8a98780, w=w@entry=0x8c8e128, mask=mask@entry=10, region=..., data=...) at ../../kwin/effects.cpp:281 #26 0xb69a4312 in KWin::Effect::paintWindow (this=0x8adc6b8, w=0x8c8e128, mask=10, region=..., data=...) at ../../../kwin/libkwineffects/kwineffects.cpp:504 #27 0xb7750723 in KWin::EffectsHandlerImpl::paintWindow (this=0x8a98780, w=0x8c8e128, mask=mask@entry=10, region=..., data=...) at ../../kwin/effects.cpp:278 #28 0xb772e130 in KWin::Scene::paintWindow (this=this@entry=0x896eac8, w=0x8ca89f0, mask=10, region=..., quads=...) at ../../kwin/scene.cpp:356 #29 0xb772d296 in KWin::Scene::paintSimpleScreen (this=this@entry=0x896eac8, orig_mask=orig_mask@entry=8, region=...) at ../../kwin/scene.cpp:342 #30 0xb772af33 in KWin::Scene::finalPaintScreen (this=0x896eac8, mask=mask@entry=8, region=..., data=...) at ../../kwin/scene.cpp:186 #31 0xb7750923 in KWin::EffectsHandlerImpl::paintScreen (this=0x8a98780, mask=mask@entry=8, region=..., data=...) at ../../kwin/effects.cpp:254 #32 0xb69a438a in KWin::Effect::paintScreen (this=0x8adc6b8, mask=8, region=..., data=...) at ../../../kwin/libkwineffects/kwineffects.cpp:489 #33 0xb77508cb in KWin::EffectsHandlerImpl::paintScreen (this=0x8a98780, mask=8, region=..., data=...) at ../../kwin/effects.cpp:251 #34 0xb772c4ce in KWin::Scene::paintScreen (this=this@entry=0x896eac8, mask=mask@entry=0xbfda825c, region=region@entry=0xbfda82cc) at ../../kwin/scene.cpp:140 #35 0xb773b1cb in KWin::SceneOpenGL::paint (this=0x896eac8, damage=..., toplevels=...) at ../../kwin/scene_opengl.cpp:308 #36 0xb7724d10 in KWin::Compositor::performCompositing (this=0x8696450) at ../../kwin/composite.cpp:610 #37 0xb5feb2d4 in QObject::event (this=0x8696450, e=0xbfda87f0) at kernel/qobject.cpp:1156 #38 0xb54bec7c in QApplicationPrivate::notify_helper (this=0x8554d40, receiver=0x8696450, e=0xbfda87f0) at kernel/qapplication.cpp:4567 #39 0xb54c1b94 in QApplication::notify (this=0xbfda87f0, receiver=0x8696450, e=0xbfda87f0) at kernel/qapplication.cpp:3949 #40 0xb7254d01 in KApplication::notify (this=this@entry=0xbfda8bb8, receiver=receiver@entry=0x8696450, event=event@entry=0xbfda87f0) at ../../kdeui/kernel/kapplication.cpp:311 #41 0xb76d1e0f in notify (e=0xbfda87f0, o=0x8696450, this=0xbfda8bb8) at ../../kwin/main.cpp:371 #42 KWin::Application::notify (this=0xbfda8bb8, o=0x8696450, e=0xbfda87f0) at ../../kwin/main.cpp:367 #43 0xb5fcf90e in QCoreApplication::notifyInternal (this=0xbfda8bb8, receiver=0x8696450, event=event@entry=0xbfda87f0) at kernel/qcoreapplication.cpp:946 #44 0xb60048c0 in sendEvent (event=0xbfda87f0, receiver=<optimized out>) at ../../include/QtCore/../../src/corelib/kernel/qcoreapplication.h:231 #45 QTimerInfoList::activateTimers (this=0x8555624) at kernel/qeventdispatcher_unix.cpp:622 #46 0xb6004945 in QEventDispatcherUNIX::activateTimers (this=0x8555624, this@entry=0x850beb8) at kernel/qeventdispatcher_unix.cpp:879 #47 0xb6004ab8 in QEventDispatcherUNIX::processEvents (this=this@entry=0x850beb8, flags=...) at kernel/qeventdispatcher_unix.cpp:941 #48 0xb55765f3 in QEventDispatcherX11::processEvents (this=0x850beb8, flags=...) at kernel/qeventdispatcher_x11.cpp:152 #49 0xb5fce3ec in QEventLoop::processEvents (this=this@entry=0xbfda8a38, flags=...) at kernel/qeventloop.cpp:149 #50 0xb5fce6e1 in QEventLoop::exec (this=this@entry=0xbfda8a38, flags=...) at kernel/qeventloop.cpp:204 #51 0xb5fd43fa in QCoreApplication::exec () at kernel/qcoreapplication.cpp:1218 #52 0xb54bcfc4 in QApplication::exec () at kernel/qapplication.cpp:3828 #53 0xb76d18c1 in kdemain (argc=3, argv=0xbfda8ca4) at ../../kwin/main.cpp:537 #54 0x0804855b in main (argc=3, argv=0xbfda8ca4) at kwin_dummy.cpp:3 Reported using DrKonqi
*** Bug 320354 has been marked as a duplicate of this bug. ***
@Pascal Is "heavy disk i/o" triggered by some copy action and esp. there's some popup displaying the copy process (and is this here also a problem when shutting down the desktop: "kquitapp plasma-desktop")?
Sorry for late reply. It could be a 'cp' command in konsole. Are you sure the added crash is not related to bug 311799 instead?
I just experienced the lag while doing a "apt-get dist-upgrade" in the background. It lagged during present windows, although I had used it just a few minutes ago.
Yeah, no - in this case rather not related to the spinner. - Have you tried the behavior w/ XRender compositing? - What happens on "synthetic" I/O like "cat /dev/zero > /dev/null"? - Did you try moving the plasma theme caches into RAM (ie to some tempfs mountpoint)? (see comment #27)
Hi thomas I will not do more debugging, since I don't understand it and it is too time consuming for me. I just thought that you guys could look at the code and say "hey, yeah we are doing this disc access that we could cache instead" and that would solve the problem. Also I seem to be the only one experiencing this, so I'm ready to stop this report here.