From: Feng Tang <feng.tang@intel.com> To: Thomas Zimmermann <tzimmermann@suse.de> Cc: "Stephen Rothwell" <sfr@canb.auug.org.au>, michel@daenzer.net, linux-kernel@vger.kernel.org, dri-devel <dri-devel@lists.freedesktop.org>, "Noralf Trønnes" <noralf@tronnes.org>, "Daniel Vetter" <daniel@ffwll.ch>, lkp@01.org Subject: Re: [LKP] [drm/mgag200] 90f479ae51: vm-scalability.median -18.8% regression Date: Fri, 16 Aug 2019 14:55:48 +0800 [thread overview] Message-ID: <20190816065548.GA67708@shbuild999.sh.intel.com> (raw) In-Reply-To: <20190813093616.GA65475@shbuild999.sh.intel.com> Hi Thomas, On Tue, Aug 13, 2019 at 05:36:16PM +0800, Feng Tang wrote: > Hi Thomas, > > On Mon, Aug 12, 2019 at 03:25:45PM +0800, Feng Tang wrote: > > Hi Thomas, > > > > On Fri, Aug 09, 2019 at 04:12:29PM +0800, Rong Chen wrote: > > > Hi, > > > > > > >>Actually we run the benchmark as a background process, do we need to > > > >>disable the cursor and test again? > > > >There's a worker thread that updates the display from the shadow buffer. > > > >The blinking cursor periodically triggers the worker thread, but the > > > >actual update is just the size of one character. > > > > > > > >The point of the test without output is to see if the regression comes > > > >from the buffer update (i.e., the memcpy from shadow buffer to VRAM), or > > > >from the worker thread. If the regression goes away after disabling the > > > >blinking cursor, then the worker thread is the problem. If it already > > > >goes away if there's simply no output from the test, the screen update > > > >is the problem. On my machine I have to disable the blinking cursor, so > > > >I think the worker causes the performance drop. > > > > > > We disabled redirecting stdout/stderr to /dev/kmsg, and the regression is > > > gone. > > > > > > 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 > > > \ | \ > > > 43785 44481 > > > vm-scalability/300s-8T-anon-cow-seq-hugetlb/lkp-knm01 > > > 43785 44481 GEO-MEAN vm-scalability.median > > > > Till now, from Rong's tests: > > 1. Disabling cursor blinking doesn't cure the regression. > > 2. Disabling printint test results to console can workaround the > > regression. > > > > Also if we set the perfer_shadown to 0, the regression is also > > gone. > > We also did some further break down for the time consumed by the > new code. > > The drm_fb_helper_dirty_work() calls sequentially > 1. drm_client_buffer_vmap (290 us) > 2. drm_fb_helper_dirty_blit_real (19240 us) > 3. helper->fb->funcs->dirty() ---> NULL for mgag200 driver > 4. drm_client_buffer_vunmap (215 us) > > The average run time is listed after the function names. > > From it, we can see drm_fb_helper_dirty_blit_real() takes too long > time (about 20ms for each run). I guess this is the root cause > of this regression, as the original code doesn't use this dirty worker. > > As said in last email, setting the prefer_shadow to 0 can avoid > the regrssion. Could it be an option? Any comments on this? thanks - Feng > > Thanks, > Feng > > > > > --- a/drivers/gpu/drm/mgag200/mgag200_main.c > > +++ b/drivers/gpu/drm/mgag200/mgag200_main.c > > @@ -167,7 +167,7 @@ int mgag200_driver_load(struct drm_device *dev, unsigned long flags) > > dev->mode_config.preferred_depth = 16; > > else > > dev->mode_config.preferred_depth = 32; > > - dev->mode_config.prefer_shadow = 1; > > + dev->mode_config.prefer_shadow = 0; > > > > And from the perf data, one obvious difference is good case don't > > call drm_fb_helper_dirty_work(), while bad case calls. > > > > Thanks, > > Feng > > > > > Best Regards, > > > Rong Chen > _______________________________________________ > LKP mailing list > LKP@lists.01.org > https://lists.01.org/mailman/listinfo/lkp
WARNING: multiple messages have this Message-ID (diff)
From: Feng Tang <feng.tang@intel.com> To: lkp@lists.01.org Subject: Re: [drm/mgag200] 90f479ae51: vm-scalability.median -18.8% regression Date: Fri, 16 Aug 2019 14:55:48 +0800 [thread overview] Message-ID: <20190816065548.GA67708@shbuild999.sh.intel.com> (raw) In-Reply-To: <20190813093616.GA65475@shbuild999.sh.intel.com> [-- Attachment #1: Type: text/plain, Size: 3847 bytes --] Hi Thomas, On Tue, Aug 13, 2019 at 05:36:16PM +0800, Feng Tang wrote: > Hi Thomas, > > On Mon, Aug 12, 2019 at 03:25:45PM +0800, Feng Tang wrote: > > Hi Thomas, > > > > On Fri, Aug 09, 2019 at 04:12:29PM +0800, Rong Chen wrote: > > > Hi, > > > > > > >>Actually we run the benchmark as a background process, do we need to > > > >>disable the cursor and test again? > > > >There's a worker thread that updates the display from the shadow buffer. > > > >The blinking cursor periodically triggers the worker thread, but the > > > >actual update is just the size of one character. > > > > > > > >The point of the test without output is to see if the regression comes > > > >from the buffer update (i.e., the memcpy from shadow buffer to VRAM), or > > > >from the worker thread. If the regression goes away after disabling the > > > >blinking cursor, then the worker thread is the problem. If it already > > > >goes away if there's simply no output from the test, the screen update > > > >is the problem. On my machine I have to disable the blinking cursor, so > > > >I think the worker causes the performance drop. > > > > > > We disabled redirecting stdout/stderr to /dev/kmsg, and the regression is > > > gone. > > > > > > 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 > > > \ | \ > > > 43785 44481 > > > vm-scalability/300s-8T-anon-cow-seq-hugetlb/lkp-knm01 > > > 43785 44481 GEO-MEAN vm-scalability.median > > > > Till now, from Rong's tests: > > 1. Disabling cursor blinking doesn't cure the regression. > > 2. Disabling printint test results to console can workaround the > > regression. > > > > Also if we set the perfer_shadown to 0, the regression is also > > gone. > > We also did some further break down for the time consumed by the > new code. > > The drm_fb_helper_dirty_work() calls sequentially > 1. drm_client_buffer_vmap (290 us) > 2. drm_fb_helper_dirty_blit_real (19240 us) > 3. helper->fb->funcs->dirty() ---> NULL for mgag200 driver > 4. drm_client_buffer_vunmap (215 us) > > The average run time is listed after the function names. > > From it, we can see drm_fb_helper_dirty_blit_real() takes too long > time (about 20ms for each run). I guess this is the root cause > of this regression, as the original code doesn't use this dirty worker. > > As said in last email, setting the prefer_shadow to 0 can avoid > the regrssion. Could it be an option? Any comments on this? thanks - Feng > > Thanks, > Feng > > > > > --- a/drivers/gpu/drm/mgag200/mgag200_main.c > > +++ b/drivers/gpu/drm/mgag200/mgag200_main.c > > @@ -167,7 +167,7 @@ int mgag200_driver_load(struct drm_device *dev, unsigned long flags) > > dev->mode_config.preferred_depth = 16; > > else > > dev->mode_config.preferred_depth = 32; > > - dev->mode_config.prefer_shadow = 1; > > + dev->mode_config.prefer_shadow = 0; > > > > And from the perf data, one obvious difference is good case don't > > call drm_fb_helper_dirty_work(), while bad case calls. > > > > Thanks, > > Feng > > > > > Best Regards, > > > Rong Chen > _______________________________________________ > LKP mailing list > LKP(a)lists.01.org > https://lists.01.org/mailman/listinfo/lkp
next prev parent reply other threads:[~2019-08-16 6:55 UTC|newest] Thread overview: 132+ messages / expand[flat|nested] mbox.gz Atom feed top 2019-07-29 9:51 [drm/mgag200] 90f479ae51: vm-scalability.median -18.8% regression kernel test robot 2019-07-29 9:51 ` kernel test robot 2019-07-30 17:50 ` Thomas Zimmermann 2019-07-30 17:50 ` Thomas Zimmermann 2019-07-30 18:12 ` Daniel Vetter 2019-07-30 18:12 ` Daniel Vetter 2019-07-30 18:50 ` Thomas Zimmermann 2019-07-30 18:50 ` Thomas Zimmermann 2019-07-30 18:59 ` Daniel Vetter 2019-07-30 18:59 ` Daniel Vetter 2019-07-30 20:26 ` Dave Airlie 2019-07-30 20:26 ` Dave Airlie 2019-07-31 8:13 ` Daniel Vetter 2019-07-31 8:13 ` Daniel Vetter 2019-07-31 9:25 ` [LKP] " Huang, Ying 2019-07-31 9:25 ` Huang, Ying 2019-07-31 10:12 ` [LKP] " Thomas Zimmermann 2019-07-31 10:12 ` Thomas Zimmermann 2019-07-31 10:21 ` [LKP] " Michel Dänzer 2019-08-01 6:19 ` Rong Chen 2019-08-01 6:19 ` Rong Chen 2019-08-01 8:37 ` [LKP] " Feng Tang 2019-08-01 8:37 ` Feng Tang 2019-08-01 9:59 ` [LKP] " Thomas Zimmermann 2019-08-01 9:59 ` Thomas Zimmermann 2019-08-01 11:25 ` [LKP] " Feng Tang 2019-08-01 11:25 ` Feng Tang 2019-08-01 11:58 ` [LKP] " Thomas Zimmermann 2019-08-01 11:58 ` Thomas Zimmermann 2019-08-02 7:11 ` [LKP] " Rong Chen 2019-08-02 7:11 ` Rong Chen 2019-08-02 8:23 ` [LKP] " Thomas Zimmermann 2019-08-02 8:23 ` Thomas Zimmermann 2019-08-02 9:20 ` [LKP] " Thomas Zimmermann 2019-08-02 9:20 ` Thomas Zimmermann 2019-08-01 9:57 ` [LKP] " Thomas Zimmermann 2019-08-01 9:57 ` Thomas Zimmermann 2019-08-01 13:30 ` [LKP] " Michel Dänzer 2019-08-02 8:17 ` Thomas Zimmermann 2019-08-02 8:17 ` Thomas Zimmermann 2019-07-31 10:10 ` Thomas Zimmermann 2019-07-31 10:10 ` Thomas Zimmermann 2019-08-02 9:11 ` Daniel Vetter 2019-08-02 9:11 ` Daniel Vetter 2019-08-02 9:26 ` Thomas Zimmermann 2019-08-02 9:26 ` Thomas Zimmermann 2019-08-04 18:39 ` Thomas Zimmermann 2019-08-04 18:39 ` Thomas Zimmermann 2019-08-05 7:02 ` Feng Tang 2019-08-05 7:02 ` Feng Tang 2019-08-05 7:28 ` Rong Chen 2019-08-05 10:25 ` Thomas Zimmermann 2019-08-05 10:25 ` Thomas Zimmermann 2019-08-06 12:59 ` [LKP] " Chen, Rong A 2019-08-06 12:59 ` Chen, Rong A 2019-08-07 10:42 ` [LKP] " Thomas Zimmermann 2019-08-07 10:42 ` Thomas Zimmermann 2019-08-09 8:12 ` [LKP] " Rong Chen 2019-08-09 8:12 ` Rong Chen 2019-08-12 7:25 ` [LKP] " Feng Tang 2019-08-12 7:25 ` Feng Tang 2019-08-13 9:36 ` [LKP] " Feng Tang 2019-08-13 9:36 ` Feng Tang 2019-08-13 9:36 ` [LKP] " Feng Tang 2019-08-16 6:55 ` Feng Tang [this message] 2019-08-16 6:55 ` Feng Tang 2019-08-22 17:25 ` [LKP] " Thomas Zimmermann 2019-08-22 17:25 ` Thomas Zimmermann 2019-08-22 17:25 ` [LKP] " Thomas Zimmermann 2019-08-22 20:02 ` Dave Airlie 2019-08-22 20:02 ` Dave Airlie 2019-08-23 9:54 ` [LKP] " Thomas Zimmermann 2019-08-23 9:54 ` Thomas Zimmermann 2019-08-23 9:54 ` [LKP] " Thomas Zimmermann 2019-08-24 5:16 ` Feng Tang 2019-08-24 5:16 ` Feng Tang 2019-08-24 5:16 ` [LKP] " Feng Tang 2019-08-26 10:50 ` Thomas Zimmermann 2019-08-26 10:50 ` Thomas Zimmermann 2019-08-27 12:33 ` [LKP] " Chen, Rong A 2019-08-27 12:33 ` Chen, Rong A 2019-08-27 12:33 ` [LKP] " Chen, Rong A 2019-08-27 17:16 ` Thomas Zimmermann 2019-08-27 17:16 ` Thomas Zimmermann 2019-08-28 9:37 ` [LKP] " Rong Chen 2019-08-28 9:37 ` Rong Chen 2019-08-28 10:51 ` [LKP] " Thomas Zimmermann 2019-08-28 10:51 ` Thomas Zimmermann 2019-09-04 6:27 ` [LKP] " Feng Tang 2019-09-04 6:27 ` Feng Tang 2019-09-04 6:53 ` [LKP] " Thomas Zimmermann 2019-09-04 6:53 ` Thomas Zimmermann 2019-09-04 8:11 ` [LKP] " Daniel Vetter 2019-09-04 8:11 ` Daniel Vetter 2019-09-04 8:35 ` [LKP] " Feng Tang 2019-09-04 8:35 ` Feng Tang 2019-09-04 8:43 ` [LKP] " Thomas Zimmermann 2019-09-04 8:43 ` Thomas Zimmermann 2019-09-04 14:30 ` [LKP] " Chen, Rong A 2019-09-04 14:30 ` Chen, Rong A 2019-09-04 9:17 ` [LKP] " Daniel Vetter 2019-09-04 9:17 ` Daniel Vetter 2019-09-04 11:15 ` [LKP] " Dave Airlie 2019-09-04 11:15 ` Dave Airlie 2019-09-04 11:20 ` [LKP] " Daniel Vetter 2019-09-04 11:20 ` Daniel Vetter 2019-09-04 11:20 ` [LKP] " Daniel Vetter 2019-09-05 6:59 ` Feng Tang 2019-09-05 6:59 ` Feng Tang 2019-09-05 10:37 ` [LKP] " Daniel Vetter 2019-09-05 10:37 ` Daniel Vetter 2019-09-05 10:48 ` [LKP] " Feng Tang 2019-09-05 10:48 ` Feng Tang 2019-09-05 10:48 ` [LKP] " Feng Tang 2019-09-09 14:12 ` Thomas Zimmermann 2019-09-09 14:12 ` Thomas Zimmermann 2019-09-09 14:12 ` [LKP] " Thomas Zimmermann 2019-09-16 9:06 ` Feng Tang 2019-09-16 9:06 ` Feng Tang 2019-09-17 8:48 ` [LKP] " Thomas Zimmermann 2019-09-17 8:48 ` Thomas Zimmermann 2019-09-17 8:48 ` [LKP] " Thomas Zimmermann 2019-08-05 10:22 ` Thomas Zimmermann 2019-08-05 10:22 ` Thomas Zimmermann 2019-08-05 12:52 ` Feng Tang 2019-08-05 12:52 ` Feng Tang 2020-01-06 13:19 ` Thomas Zimmermann 2020-01-06 13:19 ` Thomas Zimmermann 2020-01-08 2:25 ` Rong Chen 2020-01-08 2:28 ` Rong Chen 2020-01-08 5:20 ` Thomas Zimmermann 2020-01-08 5:20 ` 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=20190816065548.GA67708@shbuild999.sh.intel.com \ --to=feng.tang@intel.com \ --cc=daniel@ffwll.ch \ --cc=dri-devel@lists.freedesktop.org \ --cc=linux-kernel@vger.kernel.org \ --cc=lkp@01.org \ --cc=michel@daenzer.net \ --cc=noralf@tronnes.org \ --cc=sfr@canb.auug.org.au \ --cc=tzimmermann@suse.de \ /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: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.