linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* 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 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

* 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

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).