Hi Thomas,
The previous throughput was reduced from 43955 to 35691, and there is a little increase in next-20200106,
but there is no obvious change after the patchset:
commit:
f1f8555dfb ("drm/bochs: Use shadow buffer for bochs framebuffer console")
90f479ae51 ("drm/mgag200: Replace struct mga_fbdev with generic framebuffer emulation")
f1f8555dfb9a70a2 90f479ae51afa45efab97afdde9
---------------- ---------------------------
%stddev %change %stddev
\ | \
43955 ± 2% -18.8% 35691 vm-scalability.median
commit:
9eb1b48ca4 ("Add linux-next specific files for 20200106")
5f20199bac ("drm/fb-helper: Synchronize dirty worker with vblank")
next-20200106 5f20199bac9b2de71fd2158b90
---------------- --------------------------
%stddev change %stddev
\ | \
38550 38744
38549 38744 vm-scalability.median
Best Regards,
Rong Chen
On 1/6/20 9:19 PM, Thomas Zimmermann
wrote:
Hi Feng,
do you still have the test setup that produced the performance penalty?
If so, could you give a try to the patchset at [1]? I think I've fixed
the remaining issues in earlier versions and I'd like to see if it
actually improves performance.
Best regards
Thomas
[1]
https://lists.freedesktop.org/archives/dri-devel/2019-December/247771.html
Am 05.08.19 um 14:52 schrieb Feng Tang:
Hi Thomas,
On Mon, Aug 05, 2019 at 12:22:11PM +0200, Thomas Zimmermann wrote:
[snip]
2019-08-03 19:29:17 ./case-anon-cow-seq-hugetlb
2019-08-03 19:29:17 ./usemem --runtime 300 -n 4 --prealloc --prefault
-O -U 815394406
917318700 bytes / 659419 usecs = 1358497 KB/s
917318700 bytes / 659658 usecs = 1358005 KB/s
917318700 bytes / 659916 usecs = 1357474 KB/s
917318700 bytes / 660168 usecs = 1356956 KB/s
Rong, Feng, could you confirm this by disabling the cursor or blinking?
Glad to know this method restored the drop. Rong is running the case.
While I have another finds, as I noticed your patch changed the bpp from
24 to 32, I had a patch to change it back to 24, and run the case in
the weekend, the -18% regrssion was reduced to about -5%. Could this
be related?
In the original code, the fbdev console already ran with 32 bpp [1] and
16 bpp was selected for low-end devices. [2][3] The patch only set the
same values for userspace; nothing changed for the console.
I did the experiment becasue I checked the commit
90f479ae51afa4 drm/mgag200: Replace struct mga_fbdev with generic framebuffer emulation
in which there is code:
diff --git a/drivers/gpu/drm/mgag200/mgag200_main.c b/drivers/gpu/drm/mgag200/mgag200_main.c
index b10f726..a977333 100644
--- a/drivers/gpu/drm/mgag200/mgag200_main.c
+++ b/drivers/gpu/drm/mgag200/mgag200_main.c
@@ -162,7 +162,7 @@ int mgag200_driver_load(struct drm_device *dev, unsigned long flags)
if (IS_G200_SE(mdev) && mdev->mc.vram_size < (2048*1024))
dev->mode_config.preferred_depth = 16;
else
- dev->mode_config.preferred_depth = 24;
+ dev->mode_config.preferred_depth = 32;
dev->mode_config.prefer_shadow = 1;
My debug patch was kind of restoring of this part.
Thanks,
Feng
Best regards
Thomas
[1]
https://cgit.freedesktop.org/drm/drm-tip/tree/drivers/gpu/drm/mgag200/mgag200_fb.c?id=5d17718997367c435dbe5341a8e270d9b19478d3#n259
[2]
https://cgit.freedesktop.org/drm/drm-tip/tree/drivers/gpu/drm/mgag200/mgag200_fb.c?id=5d17718997367c435dbe5341a8e270d9b19478d3#n263
[3]
https://cgit.freedesktop.org/drm/drm-tip/tree/drivers/gpu/drm/mgag200/mgag200_fb.c?id=5d17718997367c435dbe5341a8e270d9b19478d3#n286
commit:
f1f8555dfb9 drm/bochs: Use shadow buffer for bochs framebuffer console
90f479ae51a drm/mgag200: Replace struct mga_fbdev with generic framebuffer emulation
01e75fea0d5 mgag200: restore the depth back to 24
f1f8555dfb9a70a2 90f479ae51afa45efab97afdde9 01e75fea0d5ff39d3e588c20ec5
---------------- --------------------------- ---------------------------
43921 ± 2% -18.3% 35884 -4.8% 41826 vm-scalability.median
14889337 -17.5% 12291029 -4.1% 14278574 vm-scalability.throughput
commit 01e75fea0d5ff39d3e588c20ec52e7a4e6588a74
Author: Feng Tang <feng.tang@xxxxxxxxx>
Date: Fri Aug 2 15:09:19 2019 +0800
mgag200: restore the depth back to 24
Signed-off-by: Feng Tang <feng.tang@xxxxxxxxx>
diff --git a/drivers/gpu/drm/mgag200/mgag200_main.c b/drivers/gpu/drm/mgag200/mgag200_main.c
index a977333..ac8f6c9 100644
--- a/drivers/gpu/drm/mgag200/mgag200_main.c
+++ b/drivers/gpu/drm/mgag200/mgag200_main.c
@@ -162,7 +162,7 @@ int mgag200_driver_load(struct drm_device *dev, unsigned long flags)
if (IS_G200_SE(mdev) && mdev->mc.vram_size < (2048*1024))
dev->mode_config.preferred_depth = 16;
else
- dev->mode_config.preferred_depth = 32;
+ dev->mode_config.preferred_depth = 24;> dev->mode_config.prefer_shadow = 1;
r = mgag200_modeset_init(mdev);
Thanks,
Feng
The difference between mgag200's original fbdev support and generic
fbdev emulation is generic fbdev's worker task that updates the VRAM
buffer from the shadow buffer. mgag200 does this immediately, but relies
on drm_can_sleep(), which is deprecated.
I think that the worker task interferes with the test case, as the
worker has been in fbdev emulation since forever and no performance
regressions have been reported so far.
So unless there's a report where this problem happens in a real-world
use case, I'd like to keep code as it is. And apparently there's always
the workaround of disabling the cursor blinking.
Best regards
Thomas
--
Thomas Zimmermann
Graphics Driver Developer
SUSE Linux GmbH, Maxfeldstrasse 5, 90409 Nuernberg, Germany
GF: Felix Imendörffer, Mary Higgins, Sri Rasiah
HRB 21284 (AG Nürnberg)
_______________________________________________
dri-devel mailing list
dri-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/dri-devel
|
