From: Rong Chen <rong.a.chen@intel.com>
To: Thomas Zimmermann <tzimmermann@suse.de>, Feng Tang <feng.tang@intel.com>
Cc: Stephen Rothwell <sfr@canb.auug.org.au>,
michel@daenzer.net, lkp@01.org,
dri-devel <dri-devel@lists.freedesktop.org>,
ying.huang@intel.com
Subject: Re: [drm/mgag200] 90f479ae51: vm-scalability.median -18.8% regression
Date: Wed, 8 Jan 2020 10:25:11 +0800 [thread overview]
Message-ID: <654bacf5-0567-0552-5cdb-c155d96d92bf@intel.com> (raw)
In-Reply-To: <89eedbfc-6174-e59d-921e-b92d11a52331@suse.de>
[-- Attachment #1.1: Type: text/plain, Size: 6625 bytes --]
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@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
>>
[-- Attachment #1.2: Type: text/html, Size: 8925 bytes --]
[-- Attachment #2: Type: text/plain, Size: 160 bytes --]
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
next prev parent reply other threads:[~2020-01-08 2:25 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
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 [this message]
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=654bacf5-0567-0552-5cdb-c155d96d92bf@intel.com \
--to=rong.a.chen@intel.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=feng.tang@intel.com \
--cc=lkp@01.org \
--cc=michel@daenzer.net \
--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).