xmodmap really slow

[Alan Hourihane]

Anyone tried just doing this recently....

xmodmap -pke > /tmp/keydump
xmodmap /tmp/keydump

And watch the Xserver hang for quite some time.

Alan.

_______________________________________________
xorg-***@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-dev

[Peter Hutterer]

Post by Alan Hourihane
Anyone tried just doing this recently....
xmodmap -pke > /tmp/keydump
xmodmap /tmp/keydump
And watch the Xserver hang for quite some time.

anything in the log? Just tried this locally and it worked just fine.
what server version are you on?

Cheers,
Peter
_______________________________________________
xorg-***@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: https://lists.x.org/mailman/li

[Alan Hourihane]

Post by Peter Hutterer

Post by Alan Hourihane
Anyone tried just doing this recently....
xmodmap -pke > /tmp/keydump
xmodmap /tmp/keydump
And watch the Xserver hang for quite some time.

anything in the log? Just tried this locally and it worked just fine.
what server version are you on?

Tried this on up-to-date Gentoo which is running 1.19.5, and also
Xwayland on Ubuntu 18.04 and both hang for quite some seconds.

Nothing in the X log at all.

Alan.
_______________________________________________
xorg-***@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: h

[Adam Jackson]

Post by Alan Hourihane
Anyone tried just doing this recently....
xmodmap -pke > /tmp/keydump
xmodmap /tmp/keydump
And watch the Xserver hang for quite some time.

Seems to be nearly instantaneous against an Xvfb, but did cause a
noticable hiccup with Xorg. Haven't investigated more closely, so I'd
suspect (in rough order of likelihood):

a) something super-linear in the number of input devices
b) some weird slow ioctl syncing the X state to the kernel
c) somehow you end up on the "lets spawn xkbcomp" path and the
fork/exec overhead kills you

- ajax
_______________________________________________
xorg-***@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-deve

[Alan Hourihane]

Post by Adam Jackson

Post by Alan Hourihane
Anyone tried just doing this recently....
xmodmap -pke > /tmp/keydump
xmodmap /tmp/keydump
And watch the Xserver hang for quite some time.

Seems to be nearly instantaneous against an Xvfb, but did cause a
noticable hiccup with Xorg. Haven't investigated more closely, so I'd
a) something super-linear in the number of input devices
b) some weird slow ioctl syncing the X state to the kernel
c) somehow you end up on the "lets spawn xkbcomp" path and the
fork/exec overhead kills you

Definitely not the last, moving "xkbcomp" from /usr/bin results in the
same issue.

Alan.
_______________________________________________
xorg-***@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: https://lists.x.org

[Alan Hourihane]

Post by Alan Hourihane

Post by Adam Jackson

Post by Alan Hourihane
Anyone tried just doing this recently....
xmodmap -pke > /tmp/keydump
xmodmap /tmp/keydump
And watch the Xserver hang for quite some time.

Seems to be nearly instantaneous against an Xvfb, but did cause a
noticable hiccup with Xorg. Haven't investigated more closely, so I'd
a) something super-linear in the number of input devices
b) some weird slow ioctl syncing the X state to the kernel
c) somehow you end up on the "lets spawn xkbcomp" path and the
fork/exec overhead kills you

Definitely not the last, moving "xkbcomp" from /usr/bin results in the
same issue.

Just checking.....

Has anyone looked into this issue ?

Alan.

_______________________________________________
xorg-***@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: https://lis

[Alan Hourihane]

Post by Alan Hourihane

Post by Alan Hourihane

Post by Adam Jackson

Post by Alan Hourihane
Anyone tried just doing this recently....
xmodmap -pke > /tmp/keydump
xmodmap /tmp/keydump
And watch the Xserver hang for quite some time.

Seems to be nearly instantaneous against an Xvfb, but did cause a
noticable hiccup with Xorg. Haven't investigated more closely, so I'd
a) something super-linear in the number of input devices
b) some weird slow ioctl syncing the X state to the kernel
c) somehow you end up on the "lets spawn xkbcomp" path and the
fork/exec overhead kills you

Definitely not the last, moving "xkbcomp" from /usr/bin results in the
same issue.

Just checking.....
Has anyone looked into this issue ?

Running perf top while it's happening shows this....

    26.77%  Xorg           [.] ResourceClientBits
    15.09%  Xorg           [.] GrabMatchesSecond
    12.62%  Xorg           [.] DetailSupersedesSecond.isra.1
    12.55%  Xorg           [.] DeletePassiveGrabFromList
     8.83%  Xorg           [.] GrabSupersedesSecond
     5.55%  Xorg           [.] AddPassiveGrabToList
     3.09%  Xorg           [.] DeletePassiveGrab
     2.00%  Xorg           [.] xi2mask_merge
     1.16%  libc-2.27.so   [.] _int_malloc
     0.92%  libc-2.27.so   [.] _int_free
     0.59%  Xorg           [.] XkbSendMap

Xorg is totally frozen while this is happening. No rendering occurs at all.

Alan.


_______________________________________________
xorg-***@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: https://lists.x.org/mailman/listinfo

[Olivier Fourdan]

Post by Alan Hourihane
Running perf top while it's happening shows this....
26.77% Xorg [.] ResourceClientBits
15.09% Xorg [.] GrabMatchesSecond
12.62% Xorg [.] DetailSupersedesSecond.isra.1
12.55% Xorg [.] DeletePassiveGrabFromList
8.83% Xorg [.] GrabSupersedesSecond
5.55% Xorg [.] AddPassiveGrabToList
3.09% Xorg [.] DeletePassiveGrab
2.00% Xorg [.] xi2mask_merge
1.16% libc-2.27.so [.] _int_malloc
0.92% libc-2.27.so [.] _int_free
0.59% Xorg [.] XkbSendMap
Xorg is totally frozen while this is happening. No rendering occurs at all.

ResourceClientBits() has a loop, I wonder how many times it gets
called for one xmodmap request, but we could probably cache the
resulting value since `LimitClients` is not supposed to change once
it's set and clients are started, that would save us the loop.

Cheers,
Olivier
_______________________________________________
xorg-***@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
In

[Olivier Fourdan]

That saves running the same loop over and over.

Signed-off-by: Olivier Fourdan <***@redhat.com>
---
dix/resource.c | 7 ++++++-
1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/dix/resource.c b/dix/resource.c
index b6ef99f10..e39df7773 100644
--- a/dix/resource.c
+++ b/dix/resource.c
@@ -620,7 +620,12 @@ ilog2(int val)
unsigned int
ResourceClientBits(void)
{
- return (ilog2(LimitClients));
+ static int cached = 0;
+
+ if (cached == 0)
+ cached = ilog2(LimitClients);
+
+ return cached;
}

/*****************

[Olivier Fourdan]

Post by Olivier Fourdan

Post by Alan Hourihane
Running perf top while it's happening shows this....
26.77% Xorg [.] ResourceClientBits
15.09% Xorg [.] GrabMatchesSecond
12.62% Xorg [.] DetailSupersedesSecond.isra.1
12.55% Xorg [.] DeletePassiveGrabFromList
8.83% Xorg [.] GrabSupersedesSecond
5.55% Xorg [.] AddPassiveGrabToList
3.09% Xorg [.] DeletePassiveGrab
2.00% Xorg [.] xi2mask_merge
1.16% libc-2.27.so [.] _int_malloc
0.92% libc-2.27.so [.] _int_free
0.59% Xorg [.] XkbSendMap
Xorg is totally frozen while this is happening. No rendering occurs at all.

ResourceClientBits() has a loop, I wonder how many times it gets
called for one xmodmap request, but we could probably cache the
resulting value since `LimitClients` is not supposed to change once
it's set and clients are started, that would save us the loop.

Please let me know if that patch makes any difference:

https://patchwork.freedesktop.org/series/53315/

If it helps, I'll prepare a MR.

Cheers,
Olivier
_______________________________________________
xorg-***@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: https://lists.x.org/mai