dri-devel.lists.freedesktop.org archive mirror
 help / color / mirror / Atom feed
From: Feng Tang <feng.tang@intel.com>
To: Thomas Zimmermann <tzimmermann@suse.de>
Cc: Stephen Rothwell <sfr@canb.auug.org.au>,
	kernel test robot <rong.a.chen@intel.com>,
	michel@daenzer.net, dri-devel <dri-devel@lists.freedesktop.org>,
	ying.huang@intel.com, lkp@01.org
Subject: Re: [drm/mgag200] 90f479ae51: vm-scalability.median -18.8% regression
Date: Mon, 5 Aug 2019 15:02:00 +0800	[thread overview]
Message-ID: <20190805070200.GA91650@shbuild999.sh.intel.com> (raw)
In-Reply-To: <14fdaaed-51c8-b270-b46b-cba7b5c4ba52@suse.de>

Hi Thomas,

On Sun, Aug 04, 2019 at 08:39:19PM +0200, Thomas Zimmermann wrote:
> 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?

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?

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@intel.com>
Date:   Fri Aug 2 15:09:19 2019 +0800

    mgag200: restore the depth back to 24
    
    Signed-off-by: Feng Tang <feng.tang@intel.com>

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
> 
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

  reply	other threads:[~2019-08-05  7:09 UTC|newest]

Thread overview: 61+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20190729095155.GP22106@shao2-debian>
2019-07-30 17:50 ` [drm/mgag200] 90f479ae51: vm-scalability.median -18.8% regression Thomas Zimmermann
2019-07-30 18:12   ` Daniel Vetter
2019-07-30 18:50     ` Thomas Zimmermann
2019-07-30 18:59       ` Daniel Vetter
2019-07-30 20:26         ` Dave Airlie
2019-07-31  8:13           ` Daniel Vetter
2019-07-31  9:25             ` [LKP] " Huang, Ying
2019-07-31 10:12               ` Thomas Zimmermann
2019-07-31 10:21               ` Michel Dänzer
2019-08-01  6:19                 ` Rong Chen
2019-08-01  8:37                   ` Feng Tang
2019-08-01  9:59                     ` Thomas Zimmermann
2019-08-01 11:25                       ` Feng Tang
2019-08-01 11:58                         ` Thomas Zimmermann
2019-08-02  7:11                           ` Rong Chen
2019-08-02  8:23                             ` Thomas Zimmermann
2019-08-02  9:20                             ` Thomas Zimmermann
2019-08-01  9:57                   ` Thomas Zimmermann
2019-08-01 13:30                   ` Michel Dänzer
2019-08-02  8:17                     ` Thomas Zimmermann
2019-07-31 10:10             ` Thomas Zimmermann
2019-08-02  9:11               ` Daniel Vetter
2019-08-02  9:26                 ` Thomas Zimmermann
2019-08-04 18:39   ` Thomas Zimmermann
2019-08-05  7:02     ` Feng Tang [this message]
2019-08-05 10:22       ` Thomas Zimmermann
2019-08-05 12:52         ` Feng Tang
2020-01-06 13:19           ` Thomas Zimmermann
2020-01-08  2:25             ` Rong Chen
2020-01-08  5:20               ` Thomas Zimmermann
     [not found]       ` <c0c3f387-dc93-3146-788c-23258b28a015@intel.com>
2019-08-05 10:25         ` Thomas Zimmermann
2019-08-06 12:59           ` [LKP] " Chen, Rong A
2019-08-07 10:42             ` Thomas Zimmermann
2019-08-09  8:12               ` Rong Chen
2019-08-12  7:25                 ` Feng Tang
2019-08-13  9:36                   ` Feng Tang
2019-08-16  6:55                     ` Feng Tang
2019-08-22 17:25                     ` Thomas Zimmermann
2019-08-22 20:02                       ` Dave Airlie
2019-08-23  9:54                         ` Thomas Zimmermann
2019-08-24  5:16                       ` Feng Tang
2019-08-26 10:50                         ` Thomas Zimmermann
2019-08-27 12:33                           ` Chen, Rong A
2019-08-27 17:16                             ` Thomas Zimmermann
2019-08-28  9:37                               ` Rong Chen
2019-08-28 10:51                                 ` Thomas Zimmermann
2019-09-04  6:27                                   ` Feng Tang
2019-09-04  6:53                                     ` Thomas Zimmermann
2019-09-04  8:11                                       ` Daniel Vetter
2019-09-04  8:35                                         ` Feng Tang
2019-09-04  8:43                                           ` Thomas Zimmermann
2019-09-04 14:30                                             ` Chen, Rong A
2019-09-04  9:17                                           ` Daniel Vetter
2019-09-04 11:15                                             ` Dave Airlie
2019-09-04 11:20                                               ` Daniel Vetter
2019-09-05  6:59                                                 ` Feng Tang
2019-09-05 10:37                                                   ` Daniel Vetter
2019-09-05 10:48                                                     ` Feng Tang
2019-09-09 14:12                                     ` Thomas Zimmermann
2019-09-16  9:06                                       ` Feng Tang
2019-09-17  8:48                                         ` Thomas Zimmermann

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20190805070200.GA91650@shbuild999.sh.intel.com \
    --to=feng.tang@intel.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=lkp@01.org \
    --cc=michel@daenzer.net \
    --cc=rong.a.chen@intel.com \
    --cc=sfr@canb.auug.org.au \
    --cc=tzimmermann@suse.de \
    --cc=ying.huang@intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).