Page MenuHomePhabricator

Lots of setxkbmap processes slowing down system
Closed, ResolvedPublic


I'm running Enlightenment (version 0.21.3, using X11) with latest Archlinux in an old Eeepc 1005HA. I usually have opened only midori and terminology due to low amount of resources avialable in the machine.

From time to time, I see my system slowing down to the point I can barely use it during tens of seconds. When I can finally reach the terminal, I can see a lot of "setxkbmap" processes created. Once I kill them (killall setxkbmap) my computer works correctly again.

From "pstree -a" output (attached) I see those "setxkbmap" processes are created by Enlightenment. It seems they are created using code in src/bin/e_xkb.c.

I would expect Enlightenment not to create so many simultaneous setxkbmap processes and slow down my computer as it is doing now.

Possible hint: I am experiencing some issues with my charger, as in sometimes it starts switching between AC and battery several times per second. Could that somehow trigger this behaviour? In any case, I guess there should be some code to limit the amount of processes created to avoid the situation described.

pespin created this task.Feb 15 2017, 3:43 PM

Hum thats strange, the setxkbmap command should terminate form itself ... no idea what is happening there.
The reason we spawn those processes is that something changed the set of available layouts ... Can you find out why the processes are not terminating from themselfs ?

As far as I know, the setxkbmap processes are finishing at some point without killing them. I am just killing them to be able to regain control (resources) in my netbook more quickly.
My guess is: lots of those "set of available layouts changed" events are coming really quickly at some point in time (no idea why), and then Enlightenment starts spawning a new setxkbmap process for each event. So many processes are created that it kind of takes down the system temporally (probably swap-to-disk jumps in). In turn, as the system becomes heavily loaded, it has no time to run the setxkbmap processes to let them finish in a timely fashion, that's why they queue up in there waiting for the system to let them run. Either that or setxkbmap processes block waiting for some system resource (x11?) which is also struggling to keep on at a sufficiently high speed due to the high load.

It's difficult to let you know more so far, I didn't find yet an easy way to reproduce it, but it happens from time to time while using the netbook. It's also difficult to debug the system when that happens because I only have tens of seconds and the system is really unresponsive during that time, but I consistently see a lot of setxkbmap processes when that happens. Then, when responsiveness is good again, no setxkbmap processes are showin up anymore.

In any case, if not already done, I guess Enlightenment should keep state as in "I'm running setxkbmap", and when a next event is received which would trigger a new setxkbmap process to be created, then defer the action until the old setxkbmap is finished.

Last time this issue appeared I could see that there's also an extra process named xkbcomp running during the time my system was quite unresponsive. Seems related to the same keyoard events I may be somehow receiveing in a burst:

root      6175   321  0 02:43 tty7     00:00:00 /usr/bin/xkbcomp -w 1 -R/usr/share/X11/xkb -xkm - -em1 The XKEYBOARD keymap compiler (xkbcomp) reports: -emp >  -eml Errors from xkbcomp are not fatal to the X server /var/lib/xkb/server-0.xkm

After a while, this process is not running anymore. This may give some more hins to somebody with a better knowledge on x11 input architecture.