Bug#931430: Update (X Server in PowerPC Debian SID Xorg is Unusably Slow on Wallstreet)
On 7/11/19 6:57 PM, Finn Thain wrote:
>
> On Thu, 11 Jul 2019, userm57@yahoo.com wrote:
>
>> 8) Xorg_sid_fbdev.log : Xorg log file for test (3)
>> 9) Xorg_sid_mach64.log : Xorg log file for test (4)
>
> Thanks for sending these results.
>
> Unfortunately these SID test results might be skewed because the X server
> is continually logging "dbus-core: error connecting to system bus" at 10
> times per second. So if you're using single-user mode, you may have to
> start up dbus first.
Yeah, I noticed those dbus errors. Instead of just starting dbus from
single-user, it would be easier to start multiuser, then kill wdm and
restart X from the serial console using xinit. I can run those two
tests tomorrow (repeating tests 8 and 9 above). And I'll capture the
console log for those tests.
>
> Anyway, if we assume that the measurements aren't skewed, we see that the
> majority of the the x11perf measurements have regressed (for fbdev).
>
> But note that, unlike mach64, fbdev performance depends on both the kernel
> fbdev driver and the x server fbdev driver. These test results were taken
> from different kernels.
No, for all the tests today, I used 4.19.56-debian-pmac, with the same
kernel command line (except for root=).
>
> When you make fbdev measurements, you should use the same kernel binary
> and kernel parameters for each test. In the previous fbdev test, I think
> you used a kernel that I built from Debian's .config --
>
> [ 236.387] Current Operating System: Linux mac-server 4.19.56-debian-pmac #1 Wed Jul 3 20:08:58 AEST 2019 ppc
> [ 236.387] Kernel command line: root=/dev/sda11 single ignore_loglevel printk.time console=ttyS0,9600n8 video=ofonly
>
> I think this was a good choice.
>
> Please also capture the complete console log if convenient.
>
>>
>> c) The glxgears tests are included for reference. Those results give a
>> better picture of the overall slowdown in X11 graphics from Debian 8.11
>> to Debian sid. The slowdown is most easily seen when running in
>> multiuser mode with Xfce (see particularly the last two tests in the
>> file), where the glxgears FPS is about 14.1 FPS in Debian 8.11 but only
>> 4.7 FPS in Debian sid. So perhaps there are some interrelated issues
>> with Xorg and Xfce and/or mesa-utils, especially since glxgears has
>> intermittent segmentation and illegal instruction errors (only in sid).
>>
>
> Unfortunately, glxgears doesn't reflect the "overall slowdown".
Well, glxgears accurately represents the slowness that I perceive on the
Desktop going from Debian 7.8 to 8.11 to sid. It's probably also
important that the startup time (first FPS) for glxgears is much lower
in sid, and of course the segmentation and illegal instruction errors
are probably important as well (but those may be an issue with
mesa-utils, or possibly related to the dbus issue).
> More data
> is always good, however, the x11perf microbenchmarks are more tightly
> focused.
>
>> d) It takes approximately three seconds to open an xfce4-terminal in
>> Debian 8.11, six seconds in Debian sid.
>>
>
> A 50% slowdown is serious. But it may not be caused by Xorg.
Right. The 50% slowdown could just as easily be caused by Xfce, fvwm,
or even xfce-terminal.
>
> If you were to patch the X server, or change the xorg.conf (e.g. shadowfb)
Shadowfb has no effect for mach64. I didn't test it for fbdev. For
these tests, I didn't use shadowfb, or any custom xorg.conf files.
> or downgrade all of the X server packages, and if this fixed the slowdown,
> then that would prove that the regression was in the X server.
>
> But it seems that you already have x11perf results which demonstrate an X
> server performance regression. Fixing this may or may not fix the Xfce
> slowdown. It remains to be seen.
>
>> e) Moving and resizing windows might be faster in all versions of Debian
>> if the default setting would be to highlight only the window borders
>> while moving or resizing, instead of including the window contents. This
>> is probably an Xfce setting.
>>
>
> Right. If Xfce doesn't offer this feature, there are certainly other
> window managers that do offer this.
ok. It appears that Gnome and KDE both require systemd now, at least in
Debian, and twm is a bit limited. I think Xfce uses fvwm, so I could
probably use fvwm separately without Xfce (say, by starting X with
startx). It's probably also possible to compile gnome and KDE without
systemd support, but that's beyond the scope of the current tests and
might break other things (in Debian).
>
> If this is an Xfce bug, you'll need to file a bug report against that
> package, in order to reach the relevant developers.
>
Reply to: