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 20:52:39 +0800 [thread overview] Message-ID: <20190805125239.GB96155@shbuild999.sh.intel.com> (raw) In-Reply-To: <2f524683-d9ee-77b6-1253-5645dff050a7@suse.de> 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@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 > >> > > -- > 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@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
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: Mon, 05 Aug 2019 20:52:39 +0800 [thread overview] Message-ID: <20190805125239.GB96155@shbuild999.sh.intel.com> (raw) In-Reply-To: <2f524683-d9ee-77b6-1253-5645dff050a7@suse.de> [-- Attachment #1: Type: text/plain, Size: 4880 bytes --] 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@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 > >> > > -- > 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) >
next prev parent reply other threads:[~2019-08-05 12:52 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 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 [this message] 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=20190805125239.GB96155@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: 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.