* Performance regression in ast drm driver @ 2018-11-01 15:27 Jean Delvare 2018-11-08 12:05 ` Jean Delvare 0 siblings, 1 reply; 12+ messages in thread From: Jean Delvare @ 2018-11-01 15:27 UTC (permalink / raw) To: Dave Airlie; +Cc: Christian König, Takashi Iwai, dri-devel, linux-kernel Hi David, The following commit: commit 7cf321d118a825c1541b43ca45294126fd474efa Author: Dave Airlie Date: Mon Oct 24 15:37:48 2016 +1000 drm/drivers: add support for using the arch wc mapping API. is causing a huge performance regression for the ast drm driver. In a text console, if I call "cat" on a large text file, it takes almost twice as much time to be displayed and scrolled completely. Can you please check that the ast driver portion of that commit is both correct and complete? Thanks, -- Jean Delvare SUSE L3 Support ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Performance regression in ast drm driver 2018-11-01 15:27 Performance regression in ast drm driver Jean Delvare @ 2018-11-08 12:05 ` Jean Delvare 2018-11-09 0:04 ` David Airlie 2018-11-13 8:19 ` YC Chen 0 siblings, 2 replies; 12+ messages in thread From: Jean Delvare @ 2018-11-08 12:05 UTC (permalink / raw) To: Dave Airlie; +Cc: Christian König, Takashi Iwai, dri-devel, linux-kernel On Thu, 1 Nov 2018 16:27:07 +0100, Jean Delvare wrote: > Hi David, > > The following commit: > > commit 7cf321d118a825c1541b43ca45294126fd474efa > Author: Dave Airlie > Date: Mon Oct 24 15:37:48 2016 +1000 > > drm/drivers: add support for using the arch wc mapping API. > > is causing a huge performance regression for the ast drm driver. In a > text console, if I call "cat" on a large text file, it takes almost > twice as much time to be displayed and scrolled completely. > > Can you please check that the ast driver portion of that commit is both > correct and complete? And in the meantime, what bad will happen if we just revert the ast portion of that commit? Thanks, -- Jean Delvare SUSE L3 Support ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Performance regression in ast drm driver 2018-11-08 12:05 ` Jean Delvare @ 2018-11-09 0:04 ` David Airlie 2018-11-10 8:39 ` Jean Delvare 2018-11-12 14:36 ` Jean Delvare 2018-11-13 8:19 ` YC Chen 1 sibling, 2 replies; 12+ messages in thread From: David Airlie @ 2018-11-09 0:04 UTC (permalink / raw) To: jdelvare; +Cc: christian.koenig, Iwai, Takashi, dri-devel, linux-kernel On Thu, Nov 8, 2018 at 10:05 PM Jean Delvare <jdelvare@suse.de> wrote: > > On Thu, 1 Nov 2018 16:27:07 +0100, Jean Delvare wrote: > > Hi David, > > > > The following commit: > > > > commit 7cf321d118a825c1541b43ca45294126fd474efa > > Author: Dave Airlie > > Date: Mon Oct 24 15:37:48 2016 +1000 > > > > drm/drivers: add support for using the arch wc mapping API. > > > > is causing a huge performance regression for the ast drm driver. In a > > text console, if I call "cat" on a large text file, it takes almost > > twice as much time to be displayed and scrolled completely. > > > > Can you please check that the ast driver portion of that commit is both > > correct and complete? > > And in the meantime, what bad will happen if we just revert the ast > portion of that commit? > This seems likely to be a hw problem with PCI writes to the AST "GPU", since it's just some sort of RAM + ARM on the end of a PCIE bus, we've definitely seen possible issues in the past with write combining around some of the mga GPUs with some CPUs. Have we seen the problem across a number of AST devices? Dave. ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Performance regression in ast drm driver 2018-11-09 0:04 ` David Airlie @ 2018-11-10 8:39 ` Jean Delvare 2018-11-12 14:36 ` Jean Delvare 1 sibling, 0 replies; 12+ messages in thread From: Jean Delvare @ 2018-11-10 8:39 UTC (permalink / raw) To: David Airlie; +Cc: christian.koenig, Iwai, Takashi, dri-devel, linux-kernel On Fri, 9 Nov 2018 10:04:03 +1000, David Airlie wrote: > This seems likely to be a hw problem with PCI writes to the AST "GPU", > since it's just some sort of RAM + ARM on the end of a PCIE bus, we've > definitely seen possible issues in the past with write combining > around some of the mga GPUs with some CPUs. > > Have we seen the problem across a number of AST devices? The reports I received from customers were all on AST 2500 devices (on Supermicro X11DPi-N, Supermicro X11DPH-T and Asus WS C621 Sage). I was able to reproduce "the problem" on my old Asus Z6NA-D6 which has either an AST 2050 device if I trust the board specifications on asus.com, or an AST 1100 if I trust /var/log/Xorg.0.log. Note however that I am still not certain that the problem I am seeing is the same as what both customers reported. It is possible that we have 2 different issues. -- Jean Delvare SUSE L3 Support ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Performance regression in ast drm driver 2018-11-09 0:04 ` David Airlie 2018-11-10 8:39 ` Jean Delvare @ 2018-11-12 14:36 ` Jean Delvare 2018-11-12 14:45 ` Takashi Iwai 2018-11-12 19:36 ` Thomas Zimmermann 1 sibling, 2 replies; 12+ messages in thread From: Jean Delvare @ 2018-11-12 14:36 UTC (permalink / raw) To: David Airlie; +Cc: christian.koenig, Iwai, Takashi, dri-devel, linux-kernel Hi David, On Fri, 2018-11-09 at 10:04 +1000, David Airlie wrote: > On Thu, Nov 8, 2018 at 10:05 PM Jean Delvare <jdelvare@suse.de> wrote: > > > > On Thu, 1 Nov 2018 16:27:07 +0100, Jean Delvare wrote: > > > Hi David, > > > > > > The following commit: > > > > > > commit 7cf321d118a825c1541b43ca45294126fd474efa > > > Author: Dave Airlie > > > Date: Mon Oct 24 15:37:48 2016 +1000 > > > > > > drm/drivers: add support for using the arch wc mapping API. > > > > > > is causing a huge performance regression for the ast drm driver. In a > > > text console, if I call "cat" on a large text file, it takes almost > > > twice as much time to be displayed and scrolled completely. > > > > > > Can you please check that the ast driver portion of that commit is both > > > correct and complete? > > > > And in the meantime, what bad will happen if we just revert the ast > > portion of that commit? > > This seems likely to be a hw problem with PCI writes to the AST "GPU", > since it's just some sort of RAM + ARM on the end of a PCIE bus, we've > definitely seen possible issues in the past with write combining > around some of the mga GPUs with some CPUs. Takashi asked me to compare the contents of /sys/kernel/debug/x86/pat_memtype_list before and after the commit above. Before the commit, we have: uncached-minus @ 0xfafe0000-0xfb000000 uncached-minus @ 0xfb000000-0xfb005000 write-combining @ 0xfb005000-0xfb584000 After the commit, we have: uncached-minus @ 0xfafe0000-0xfb000000 uncached-minus @ 0xfb000000-0xfb005000 uncached-minus @ 0xfb000000-0xfb800000 uncached-minus @ 0xfb005000-0xfb584000 The corresponding lines in /proc/iomem are: f0000000-fed8ffff : PCI Bus 0000:00 faf00000-fb7fffff : PCI Bus 0000:01 fafe0000-faffffff : 0000:01:01.0 fb000000-fb7fffff : 0000:01:01.0 Does it help? Is the change of type expected? Is it not a problem that one of the ranges is overlapping with 2 other ranges? -- Jean Delvare SUSE L3 Support ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Performance regression in ast drm driver 2018-11-12 14:36 ` Jean Delvare @ 2018-11-12 14:45 ` Takashi Iwai 2018-11-12 16:41 ` Jean Delvare 2018-11-12 19:36 ` Thomas Zimmermann 1 sibling, 1 reply; 12+ messages in thread From: Takashi Iwai @ 2018-11-12 14:45 UTC (permalink / raw) To: Jean Delvare; +Cc: David Airlie, christian.koenig, dri-devel, linux-kernel On Mon, 12 Nov 2018 15:36:07 +0100, Jean Delvare wrote: > > Hi David, > > On Fri, 2018-11-09 at 10:04 +1000, David Airlie wrote: > > On Thu, Nov 8, 2018 at 10:05 PM Jean Delvare <jdelvare@suse.de> wrote: > > > > > > On Thu, 1 Nov 2018 16:27:07 +0100, Jean Delvare wrote: > > > > Hi David, > > > > > > > > The following commit: > > > > > > > > commit 7cf321d118a825c1541b43ca45294126fd474efa > > > > Author: Dave Airlie > > > > Date: Mon Oct 24 15:37:48 2016 +1000 > > > > > > > > drm/drivers: add support for using the arch wc mapping API. > > > > > > > > is causing a huge performance regression for the ast drm driver. In a > > > > text console, if I call "cat" on a large text file, it takes almost > > > > twice as much time to be displayed and scrolled completely. > > > > > > > > Can you please check that the ast driver portion of that commit is both > > > > correct and complete? > > > > > > And in the meantime, what bad will happen if we just revert the ast > > > portion of that commit? > > > > This seems likely to be a hw problem with PCI writes to the AST "GPU", > > since it's just some sort of RAM + ARM on the end of a PCIE bus, we've > > definitely seen possible issues in the past with write combining > > around some of the mga GPUs with some CPUs. > > Takashi asked me to compare the contents of > /sys/kernel/debug/x86/pat_memtype_list before and after the commit > above. Before the commit, we have: > > uncached-minus @ 0xfafe0000-0xfb000000 > uncached-minus @ 0xfb000000-0xfb005000 > write-combining @ 0xfb005000-0xfb584000 > > After the commit, we have: > > uncached-minus @ 0xfafe0000-0xfb000000 > uncached-minus @ 0xfb000000-0xfb005000 > uncached-minus @ 0xfb000000-0xfb800000 > uncached-minus @ 0xfb005000-0xfb584000 Just to be sure: could you double-check whether you're checking the right order (i.e. not checking against the revert)? The change above looks illogical from what I can see from the commit... thanks, Takashi > > The corresponding lines in /proc/iomem are: > > f0000000-fed8ffff : PCI Bus 0000:00 > faf00000-fb7fffff : PCI Bus 0000:01 > fafe0000-faffffff : 0000:01:01.0 > fb000000-fb7fffff : 0000:01:01.0 > > Does it help? Is the change of type expected? Is it not a problem that > one of the ranges is overlapping with 2 other ranges? > > -- > Jean Delvare > SUSE L3 Support > ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Performance regression in ast drm driver 2018-11-12 14:45 ` Takashi Iwai @ 2018-11-12 16:41 ` Jean Delvare 2018-11-13 9:23 ` Thomas Zimmermann 0 siblings, 1 reply; 12+ messages in thread From: Jean Delvare @ 2018-11-12 16:41 UTC (permalink / raw) To: Takashi Iwai; +Cc: David Airlie, christian.koenig, dri-devel, linux-kernel On Mon, 2018-11-12 at 15:45 +0100, Takashi Iwai wrote: > On Mon, 12 Nov 2018 15:36:07 +0100, > Jean Delvare wrote: > > Takashi asked me to compare the contents of > > /sys/kernel/debug/x86/pat_memtype_list before and after the commit > > above. Before the commit, we have: > > > > uncached-minus @ 0xfafe0000-0xfb000000 > > uncached-minus @ 0xfb000000-0xfb005000 > > write-combining @ 0xfb005000-0xfb584000 > > > > After the commit, we have: > > > > uncached-minus @ 0xfafe0000-0xfb000000 > > uncached-minus @ 0xfb000000-0xfb005000 > > uncached-minus @ 0xfb000000-0xfb800000 > > uncached-minus @ 0xfb005000-0xfb584000 > > Just to be sure: > could you double-check whether you're checking the right order > (i.e. not checking against the revert)? The change above looks > illogical from what I can see from the commit... Yes, I double checked and can only confirm what I wrote above. However while checking I noticed another strange thing: the contents of pat_memtype_list depend on whether I'm reading the file from an xterm or from the text console (Ctrl+Alt+F2). So I summarize again: Commit "drm/drivers: add support for using the arch wc mapping API" APPLIED, reading pat_memtype_list from the text console: uncached-minus @ 0xfafe0000-0xfb000000 uncached-minus @ 0xfb000000-0xfb005000 uncached-minus @ 0xfb000000-0xfb800000 uncached-minus @ 0xfb005000-0xfb584000 Commit "drm/drivers: add support for using the arch wc mapping API" APPLIED, reading pat_memtype_list from an xterm: uncached-minus @ 0xfafe0000-0xfb000000 uncached-minus @ 0xfb000000-0xfb005000 uncached-minus @ 0xfb000000-0xfb800000 Commit "drm/drivers: add support for using the arch wc mapping API" REVERTED, reading pat_memtype_list from the text console: uncached-minus @ 0xfafe0000-0xfb000000 uncached-minus @ 0xfb000000-0xfb005000 write-combining @ 0xfb005000-0xfb584000 Commit "drm/drivers: add support for using the arch wc mapping API" REVERTED, reading pat_memtype_list from an xterm: uncached-minus @ 0xfafe0000-0xfb000000 uncached-minus @ 0xfb000000-0xfb005000 If you don't find it logical, remember that if things were the way they are supposed to be, customers and myself would not be reporting this bug ;-) -- Jean Delvare SUSE L3 Support ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Performance regression in ast drm driver 2018-11-12 16:41 ` Jean Delvare @ 2018-11-13 9:23 ` Thomas Zimmermann 2018-11-13 12:08 ` Jean Delvare 0 siblings, 1 reply; 12+ messages in thread From: Thomas Zimmermann @ 2018-11-13 9:23 UTC (permalink / raw) To: Jean Delvare, Takashi Iwai Cc: David Airlie, christian.koenig, dri-devel, linux-kernel [-- Attachment #1.1: Type: text/plain, Size: 2907 bytes --] Jean, ast doesn't remove the vesafb's framebuffer before attaching to the device. I have a patch at [1]. If you have a way of testing it, I'd appreciate. Best regards Thomas [1] https://bugzilla.suse.com/show_bug.cgi?id=1112963 Am 12.11.18 um 17:41 schrieb Jean Delvare: > On Mon, 2018-11-12 at 15:45 +0100, Takashi Iwai wrote: >> On Mon, 12 Nov 2018 15:36:07 +0100, >> Jean Delvare wrote: >>> Takashi asked me to compare the contents of >>> /sys/kernel/debug/x86/pat_memtype_list before and after the commit >>> above. Before the commit, we have: >>> >>> uncached-minus @ 0xfafe0000-0xfb000000 >>> uncached-minus @ 0xfb000000-0xfb005000 >>> write-combining @ 0xfb005000-0xfb584000 >>> >>> After the commit, we have: >>> >>> uncached-minus @ 0xfafe0000-0xfb000000 >>> uncached-minus @ 0xfb000000-0xfb005000 >>> uncached-minus @ 0xfb000000-0xfb800000 >>> uncached-minus @ 0xfb005000-0xfb584000 >> >> Just to be sure: >> could you double-check whether you're checking the right order >> (i.e. not checking against the revert)? The change above looks >> illogical from what I can see from the commit... > > Yes, I double checked and can only confirm what I wrote above. However > while checking I noticed another strange thing: the contents of > pat_memtype_list depend on whether I'm reading the file from an xterm > or from the text console (Ctrl+Alt+F2). So I summarize again: > > Commit "drm/drivers: add support for using the arch wc mapping API" > APPLIED, reading pat_memtype_list from the text console: > > uncached-minus @ 0xfafe0000-0xfb000000 > uncached-minus @ 0xfb000000-0xfb005000 > uncached-minus @ 0xfb000000-0xfb800000 > uncached-minus @ 0xfb005000-0xfb584000 > > Commit "drm/drivers: add support for using the arch wc mapping API" > APPLIED, reading pat_memtype_list from an xterm: > > uncached-minus @ 0xfafe0000-0xfb000000 > uncached-minus @ 0xfb000000-0xfb005000 > uncached-minus @ 0xfb000000-0xfb800000 > > Commit "drm/drivers: add support for using the arch wc mapping API" > REVERTED, reading pat_memtype_list from the text console: > > uncached-minus @ 0xfafe0000-0xfb000000 > uncached-minus @ 0xfb000000-0xfb005000 > write-combining @ 0xfb005000-0xfb584000 > > Commit "drm/drivers: add support for using the arch wc mapping API" > REVERTED, reading pat_memtype_list from an xterm: > > uncached-minus @ 0xfafe0000-0xfb000000 > uncached-minus @ 0xfb000000-0xfb005000 > > If you don't find it logical, remember that if things were the way they > are supposed to be, customers and myself would not be reporting this > bug ;-) > -- Thomas Zimmermann Graphics Driver Developer SUSE Linux GmbH, Maxfeldstr. 5, D-90409 Nürnberg Tel: +49-911-74053-0; Fax: +49-911-7417755; https://www.suse.com/ SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg) [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 488 bytes --] ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Performance regression in ast drm driver 2018-11-13 9:23 ` Thomas Zimmermann @ 2018-11-13 12:08 ` Jean Delvare 2018-11-13 12:16 ` Thomas Zimmermann 0 siblings, 1 reply; 12+ messages in thread From: Jean Delvare @ 2018-11-13 12:08 UTC (permalink / raw) To: Thomas Zimmermann Cc: Takashi Iwai, David Airlie, christian.koenig, dri-devel, linux-kernel Hi Thomas, On Tue, 13 Nov 2018 10:23:45 +0100, Thomas Zimmermann wrote: > ast doesn't remove the vesafb's framebuffer before attaching to the > device. I have a patch at [1]. If you have a way of testing it, I'd > appreciate. > > [1] https://bugzilla.suse.com/show_bug.cgi?id=1112963 Thank you very much for looking into this bug. I tested the patch above and yes, it solves my console performance problem. The performance with your patch applied is roughly the same as with commit "drm/drivers: add support for using the arch wc mapping API" reverted. -- Jean Delvare SUSE L3 Support ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Performance regression in ast drm driver 2018-11-13 12:08 ` Jean Delvare @ 2018-11-13 12:16 ` Thomas Zimmermann 0 siblings, 0 replies; 12+ messages in thread From: Thomas Zimmermann @ 2018-11-13 12:16 UTC (permalink / raw) To: Jean Delvare Cc: Takashi Iwai, David Airlie, christian.koenig, dri-devel, linux-kernel [-- Attachment #1.1: Type: text/plain, Size: 1073 bytes --] Hi Am 13.11.18 um 13:08 schrieb Jean Delvare: > Hi Thomas, > > On Tue, 13 Nov 2018 10:23:45 +0100, Thomas Zimmermann wrote: >> ast doesn't remove the vesafb's framebuffer before attaching to the >> device. I have a patch at [1]. If you have a way of testing it, I'd >> appreciate. >> >> [1] https://bugzilla.suse.com/show_bug.cgi?id=1112963 > > Thank you very much for looking into this bug. I tested the patch above > and yes, it solves my console performance problem. The performance with > your patch applied is roughly the same as with commit "drm/drivers: add > support for using the arch wc mapping API" reverted. > Great. I'll add it to SLE and also send it upstream soonish. Let's see what Edward reports. Thanks for building a kernel for him. Best regards Thomas -- Thomas Zimmermann Graphics Driver Developer SUSE Linux GmbH, Maxfeldstr. 5, D-90409 Nürnberg Tel: +49-911-74053-0; Fax: +49-911-7417755; https://www.suse.com/ SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg) [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 488 bytes --] ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Performance regression in ast drm driver 2018-11-12 14:36 ` Jean Delvare 2018-11-12 14:45 ` Takashi Iwai @ 2018-11-12 19:36 ` Thomas Zimmermann 1 sibling, 0 replies; 12+ messages in thread From: Thomas Zimmermann @ 2018-11-12 19:36 UTC (permalink / raw) To: Jean Delvare, David Airlie Cc: christian.koenig, dri-devel, linux-kernel, Takashi Iwai [-- Attachment #1.1: Type: text/plain, Size: 2835 bytes --] Hi Jean Am 12.11.18 um 15:36 schrieb Jean Delvare: > Hi David, > > On Fri, 2018-11-09 at 10:04 +1000, David Airlie wrote: >> On Thu, Nov 8, 2018 at 10:05 PM Jean Delvare <jdelvare@suse.de> wrote: >>> >>> On Thu, 1 Nov 2018 16:27:07 +0100, Jean Delvare wrote: >>>> Hi David, >>>> >>>> The following commit: >>>> >>>> commit 7cf321d118a825c1541b43ca45294126fd474efa >>>> Author: Dave Airlie >>>> Date: Mon Oct 24 15:37:48 2016 +1000 >>>> >>>> drm/drivers: add support for using the arch wc mapping API. >>>> >>>> is causing a huge performance regression for the ast drm driver. In a >>>> text console, if I call "cat" on a large text file, it takes almost >>>> twice as much time to be displayed and scrolled completely. >>>> >>>> Can you please check that the ast driver portion of that commit is both >>>> correct and complete? >>> >>> And in the meantime, what bad will happen if we just revert the ast >>> portion of that commit? >> >> This seems likely to be a hw problem with PCI writes to the AST "GPU", >> since it's just some sort of RAM + ARM on the end of a PCIE bus, we've >> definitely seen possible issues in the past with write combining >> around some of the mga GPUs with some CPUs. > > Takashi asked me to compare the contents of > /sys/kernel/debug/x86/pat_memtype_list before and after the commit > above. Before the commit, we have: > > uncached-minus @ 0xfafe0000-0xfb000000 > uncached-minus @ 0xfb000000-0xfb005000 > write-combining @ 0xfb005000-0xfb584000 > > After the commit, we have: > > uncached-minus @ 0xfafe0000-0xfb000000 > uncached-minus @ 0xfb000000-0xfb005000 > uncached-minus @ 0xfb000000-0xfb800000 > uncached-minus @ 0xfb005000-0xfb584000 > > The corresponding lines in /proc/iomem are: > > f0000000-fed8ffff : PCI Bus 0000:00 > faf00000-fb7fffff : PCI Bus 0000:01 > fafe0000-faffffff : 0000:01:01.0 > fb000000-fb7fffff : 0000:01:01.0 > > Does it help? Is the change of type expected? Is it not a problem that > one of the ranges is overlapping with 2 other ranges? > I debugged this problem with an AST 2000. What happens is that the vesafb driver attaches first to the graphics device. It disables write-combining and falls back to uncached access; unless the kernel has been booted with video=vesafb:mtrr:3. Then it will set-up WC correctly. The respective code is at [1]. Best regards Thomas [1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/video/fbdev/vesafb.c?h=v4.20-rc2#n415 -- Thomas Zimmermann Graphics Driver Developer SUSE Linux GmbH, Maxfeldstr. 5, D-90409 Nürnberg Tel: +49-911-74053-0; Fax: +49-911-7417755; https://www.suse.com/ SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg) [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 488 bytes --] ^ permalink raw reply [flat|nested] 12+ messages in thread
* RE: Performance regression in ast drm driver 2018-11-08 12:05 ` Jean Delvare 2018-11-09 0:04 ` David Airlie @ 2018-11-13 8:19 ` YC Chen 1 sibling, 0 replies; 12+ messages in thread From: YC Chen @ 2018-11-13 8:19 UTC (permalink / raw) To: Jean Delvare, Dave Airlie Cc: Christian König, dri-devel, linux-kernel, YC Chen Sir, We found the performance will be bad on desktop environment with OpenSUSE15 UEFI installation if remove "arch_io_reserve_memtype_wc". Regards, Y.C. Chen -----Original Message----- From: dri-devel [mailto:dri-devel-bounces@lists.freedesktop.org] On Behalf Of Jean Delvare Sent: Thursday, November 08, 2018 8:05 PM To: Dave Airlie <airlied@redhat.com> Cc: Christian König <christian.koenig@amd.com>; dri-devel@lists.freedesktop.org; linux-kernel@vger.kernel.org Subject: Re: Performance regression in ast drm driver On Thu, 1 Nov 2018 16:27:07 +0100, Jean Delvare wrote: > Hi David, > > The following commit: > > commit 7cf321d118a825c1541b43ca45294126fd474efa > Author: Dave Airlie > Date: Mon Oct 24 15:37:48 2016 +1000 > > drm/drivers: add support for using the arch wc mapping API. > > is causing a huge performance regression for the ast drm driver. In a > text console, if I call "cat" on a large text file, it takes almost > twice as much time to be displayed and scrolled completely. > > Can you please check that the ast driver portion of that commit is > both correct and complete? And in the meantime, what bad will happen if we just revert the ast portion of that commit? Thanks, -- Jean Delvare SUSE L3 Support _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel ^ permalink raw reply [flat|nested] 12+ messages in thread
end of thread, other threads:[~2018-11-13 12:16 UTC | newest] Thread overview: 12+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2018-11-01 15:27 Performance regression in ast drm driver Jean Delvare 2018-11-08 12:05 ` Jean Delvare 2018-11-09 0:04 ` David Airlie 2018-11-10 8:39 ` Jean Delvare 2018-11-12 14:36 ` Jean Delvare 2018-11-12 14:45 ` Takashi Iwai 2018-11-12 16:41 ` Jean Delvare 2018-11-13 9:23 ` Thomas Zimmermann 2018-11-13 12:08 ` Jean Delvare 2018-11-13 12:16 ` Thomas Zimmermann 2018-11-12 19:36 ` Thomas Zimmermann 2018-11-13 8:19 ` YC Chen
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).