On Sat, 30 Mar 2024 18:03:31 -0400 Conrad Knight <iestynap...@gmail.com> said:
first - conky is going to be pretty bad in e - at least a lot of the conky
themes use shaped windows and shaped windows n e go through a slow path of
grabbing pixel data and processing it. modern apps have moved on and use ARGB
windows which work just fine with no slow path. so first - don't use a theme
that uses shaped windows in conky (i could go into why shaped windows are kind
of bad but that'd go on for a while).
secondly i assume this has gotten to some self-feeding event loops like a lead
to b, b leads to c, c leads to a ot something. try perf top and see what
FUNCTIONS have cpu time being spent on them (especially in conky and in
enlightenment). you will need debug symbols in efl and enlightenment for this
to be useful.
but here is an interesting thijng.... kdeconnectd is also chewing cpu... id
isn't involved in the gui... keepassxc too which shouldn't be involved in the
ui... or are they doing something with x?
if you kill -STOP your conky process - does the cpu usage settle down? if there
is a a->b, b->c, c->a thing going then something conky might be doing is
leading to this if the STOP above calms it down. it'll be far easier to find
out what conky is doing (e is probably responding which leads to conky doing it
again and so on). the only USEFUL thing to do here is to get higher level
traces. for this you. you could try ltrace - but that will need symbols too.
> I'm having trouble running conky under Enlightenment recently (it
> seems to have started a month or two ago). After a while, CPU usage
> shoots up to 100% on all cores. The more conky instances i run, the
> sooner it happens, but even with only one it happens after a few
> minutes.
>
> When i hear my CPU fan start sounding like a jet engine, top shows
> that it's Enlightenment that's the main culprit, followed by every
> other Xorg process:
>
> PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
> 82569 conrad 20 0 1238632 155060 84116 R 100.0 1.0 1:36.25
> enlightenment
> 82530 conrad 20 0 587940 84100 55764 R 98.3 0.5 1:29.13 Xorg
> 82695 conrad 20 0 760092 87076 72356 S 83.4 0.5 1:14.68
> kdeconnectd
> 82593 conrad 22 2 257904 61420 33344 R 74.2 0.4 1:07.38
> terminology
> 82649 conrad 22 2 847524 116036 82764 R 63.2 0.7 0:56.30
> keepassxc 82646 conrad 23 3 427004 49676 43788 R 57.3 0.3 0:50.50
> kdeconnect-indi
> 82748 conrad 23 3 186032 22472 18504 S 30.5 0.1 0:26.80 conky
> 82747 conrad 23 3 404964 22100 18260 R 29.8 0.1 0:26.37 conky
> 82746 conrad 23 3 2996660 23856 18584 R 28.8 0.1 0:25.80 conky
> 82556 conrad 20 0 73360 5224 1920 R 19.9 0.0 0:15.30
> xbindkeys
>
> In normal usage, none of these are above 3% CPU usage, most 1% or lower.
>
> I've tested the same conkyrc files under Gnome and don't run into this
> situation. And before whatever conky update started this, i didn't
> have a problem under Enlightenment either.
>
> Can anyone suggest how to figure out what's going wrong? I attached to
> a conky process with strace immediately after starting it and saw
> nothing unusual. Then once the CPU went nuts i tried again and got
> several MB of output in a few seconds full of the same, over and over:
>
> strace: Process 74691 attached
> recvmsg(4, {msg_name=NULL, msg_namelen=0,
> msg_iov=[{iov_base="\1\2\3\27\0\0\0\0#\0\200\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\>
> recvmsg(4, {msg_name=NULL, msg_namelen=0, msg_iov=[{iov_base="\241
> \3\27\2\0\340\2-\2\0\0\2\0\340\2\0\0\0\0\0\0\0\0\0\0>
> recvmsg(4, {msg_name=NULL, msg_namelen=0, msg_iov=[{iov_base="\241
> \3\27\2\0\340\2.\2\0\0\2\0\340\2\0\0\0\0\0\0\0\0\0\0>
> recvmsg(4, {msg_namelen=0}, 0) = -1 EAGAIN (Resource
> temporarily unavailable)
> poll([{fd=4, events=POLLIN|POLLOUT}], 1, -1) = 1 ([{fd=4,
> revents=POLLIN|POLLOUT}])
> recvmsg(4, {msg_name=NULL, msg_namelen=0, msg_iov=[{iov_base="\241
> \3\27\2\0\340\2-\2\0\0\2\0\340\2\0\0\0\0\0\0\0\0\0\0>
> writev(4, [{iov_base="\31\0\v\0\371\2\0\0L\200@\0!
> \0\0\2\0\300\2.\2\0\0\2\0\300\2\0\0\0\0"..., iov_len=48}, {iov_base=>
> poll([{fd=4, events=POLLIN}], 1, -1) = 1 ([{fd=4, revents=POLLIN}])
> recvmsg(4, {msg_name=NULL, msg_namelen=0, msg_iov=[{iov_base="\241
> \4\27\2\0\300\2.\2\0\0\2\0\300\2\0\0\0\0\0\0\0\0\0\0>
> recvmsg(4, {msg_name=NULL, msg_namelen=0, msg_iov=[{iov_base="\241
> \5\27\2\0\340\2-\2\0\0\2\0\340\2\0\0\0\0\0\0\0\0\0\0>
> recvmsg(4, {msg_namelen=0}, 0) = -1 EAGAIN (Resource
> temporarily unavailable)
> poll([{fd=4, events=POLLIN|POLLOUT}], 1, -1) = 1 ([{fd=4,
> revents=POLLIN|POLLOUT}])
> recvmsg(4, {msg_name=NULL, msg_namelen=0, msg_iov=[{iov_base="\241
> \5\27\2\0\340\2.\2\0\0\2\0\340\2\0\0\0\0\0\0\0\0\0\0>
> writev(4, [{iov_base="\31\0\v\0\371\2\0\0L\200@\0!
> \0\0\2\0\300\2-\2\0\0\2\0\300\2\0\0\0\0"..., iov_len=48}, {iov_base=>
> poll([{fd=4, events=POLLIN}], 1, -1) = 1 ([{fd=4, revents=POLLIN}])
> recvmsg(4, {msg_name=NULL, msg_namelen=0, msg_iov=[{iov_base="\241
> \5\27\2\0\340\2-\2\0\0\2\0\340\2\0\0\0\0\0\0\0\0\0\0>
> poll([{fd=4, events=POLLIN}], 1, -1) = 1 ([{fd=4, revents=POLLIN}])
> recvmsg(4, {msg_name=NULL, msg_namelen=0,
> msg_iov=[{iov_base="\1\2\7\27\0\0\0\0#\0\200\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\>
> recvmsg(4, {msg_name=NULL, msg_namelen=0, msg_iov=[{iov_base="\241
> \7\27\2\0\340\2-\2\0\0\2\0\340\2\0\0\0\0\0\0\0\0\0\0>
> recvmsg(4, {msg_namelen=0}, 0) = -1 EAGAIN (Resource
> temporarily unavailable)
>
> ...ad infinitum. None of this looks particularly useful.
>
> Any suggestions?
>
> Thanks,
> -Conrad.
>
>
> --
> Shine like thunder
> Cry like rain
>
>
> _______________________________________________
> enlightenment-users mailing list
> enlightenment-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/enlightenment-users
>
--
------------- Codito, ergo sum - "I code, therefore I am" --------------
Carsten Haitzler - ras...@rasterman.com
_______________________________________________
enlightenment-users mailing list
enlightenment-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-users
