<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
Hi,<br>
<br>
<div class="moz-cite-prefix">On 8/5/2019 6:25 PM, Thomas Zimmermann
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:045a23ab-78f7-f363-4a2e-bf24a7a2f79e@suse.de">
<pre class="moz-quote-pre" wrap="">Hi
Am 05.08.19 um 09:28 schrieb Rong Chen:
</pre>
<blockquote type="cite">
<pre class="moz-quote-pre" wrap="">Hi,
On 8/5/19 3:02 PM, Feng Tang wrote:
</pre>
<blockquote type="cite">
<pre class="moz-quote-pre" wrap="">Hi Thomas,
On Sun, Aug 04, 2019 at 08:39:19PM +0200, Thomas Zimmermann wrote:
</pre>
<blockquote type="cite">
<pre class="moz-quote-pre" wrap="">Hi
I did some further analysis on this problem and found that the blinking
cursor affects performance of the vm-scalability test case.
I only have a 4-core machine, so scalability is not really testable. Yet
I see the effects of running vm-scalibility against drm-tip, a revert of
the mgag200 patch and the vmap fixes that I posted a few days ago.
After reverting the mgag200 patch, running the test as described in the
report
bin/lkp run job.yaml
gives results like
2019-08-02 19:34:37 ./case-anon-cow-seq-hugetlb
2019-08-02 19:34:37 ./usemem --runtime 300 -n 4 --prealloc
--prefault
-O -U 815395225
917319627 bytes / 756534 usecs = 1184110 KB/s
917319627 bytes / 764675 usecs = 1171504 KB/s
917319627 bytes / 766414 usecs = 1168846 KB/s
917319627 bytes / 777990 usecs = 1151454 KB/s
Running the test against current drm-tip gives slightly worse results,
such as.
2019-08-03 19:17:06 ./case-anon-cow-seq-hugetlb
2019-08-03 19:17:06 ./usemem --runtime 300 -n 4 --prealloc
--prefault
-O -U 815394406
917318700 bytes / 871607 usecs = 1027778 KB/s
917318700 bytes / 894173 usecs = 1001840 KB/s
917318700 bytes / 919694 usecs = 974040 KB/s
917318700 bytes / 923341 usecs = 970193 KB/s
The test puts out roughly one result per second. Strangely sending the
output to /dev/null can make results significantly worse.
bin/lkp run job.yaml > /dev/null
2019-08-03 19:23:04 ./case-anon-cow-seq-hugetlb
2019-08-03 19:23:04 ./usemem --runtime 300 -n 4 --prealloc
--prefault
-O -U 815394406
917318700 bytes / 1207358 usecs = 741966 KB/s
917318700 bytes / 1210456 usecs = 740067 KB/s
917318700 bytes / 1216572 usecs = 736346 KB/s
917318700 bytes / 1239152 usecs = 722929 KB/s
I realized that there's still a blinking cursor on the screen, which I
disabled with
tput civis
or alternatively
echo 0 > /sys/devices/virtual/graphics/fbcon/cursor_blink
Running the the test now gives the original or even better results,
such as
bin/lkp run job.yaml > /dev/null
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?
</pre>
</blockquote>
<pre class="moz-quote-pre" wrap="">Glad to know this method restored the drop. Rong is running the case.
</pre>
</blockquote>
<pre class="moz-quote-pre" wrap="">
I set "echo 0 > /sys/devices/virtual/graphics/fbcon/cursor_blink" for
both commits,
and the regression has no obvious change.
</pre>
</blockquote>
<pre class="moz-quote-pre" wrap="">
Ah, I see. Thank you for testing. There are two questions that come to
my mind: did you send the regular output to /dev/null? And what happens
if you disable the cursor with 'tput civis'?</pre>
</blockquote>
<br>
I didn't send the output to /dev/null because we need to collect
data from the output,<br>
Actually we run the benchmark as a background process, do we need to
disable the cursor and test again?<br>
<br>
Best Regards,<br>
Rong Chen<br>
<br>
<blockquote type="cite"
cite="mid:045a23ab-78f7-f363-4a2e-bf24a7a2f79e@suse.de">
<pre class="moz-quote-pre" wrap="">
If there is absolutely nothing changing on the screen, I don't see how
the regression could persist.
Best regards
Thomas
</pre>
<blockquote type="cite">
<pre class="moz-quote-pre" wrap="">commit:
f1f8555dfb9 drm/bochs: Use shadow buffer for bochs framebuffer console
90f479ae51a drm/mgag200: Replace struct mga_fbdev with generic
framebuffer emulation
f1f8555dfb9a70a2 90f479ae51afa45efab97afdde testcase/testparams/testbox
---------------- -------------------------- ---------------------------
%stddev change %stddev
\ | \
43394 -20% 34575 ± 3%
vm-scalability/performance-300s-8T-anon-cow-seq-hugetlb/lkp-knm01
43393 -20% 34575 GEO-MEAN
vm-scalability.median
Best Regards,
Rong Chen
</pre>
<blockquote type="cite">
<pre class="moz-quote-pre" wrap="">
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?
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 <a class="moz-txt-link-rfc2396E" href="mailto:feng.tang@intel.com"><feng.tang@intel.com></a>
Date: Fri Aug 2 15:09:19 2019 +0800
mgag200: restore the depth back to 24
Signed-off-by: Feng Tang <a class="moz-txt-link-rfc2396E" href="mailto:feng.tang@intel.com"><feng.tang@intel.com></a>
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
</pre>
<blockquote type="cite">
<pre class="moz-quote-pre" wrap="">
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
</pre>
</blockquote>
</blockquote>
<pre class="moz-quote-pre" wrap="">
</pre>
</blockquote>
<pre class="moz-quote-pre" wrap="">
</pre>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<pre class="moz-quote-pre" wrap="">_______________________________________________
LKP mailing list
<a class="moz-txt-link-abbreviated" href="mailto:LKP@lists.01.org">LKP@lists.01.org</a>
<a class="moz-txt-link-freetext" href="https://lists.01.org/mailman/listinfo/lkp">https://lists.01.org/mailman/listinfo/lkp</a>
</pre>
</blockquote>
<br>
</body>
</html>