[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CALCETrWFe+qSC9r+waf3XH-9XcrtfRMtG3AL6ndgG4PQ4QdPHQ@mail.gmail.com>
Date: Wed, 19 Jul 2017 21:28:27 -0700
From: Andy Lutomirski <luto@...nel.org>
To: Dave Airlie <airlied@...il.com>
Cc: Linus Torvalds <torvalds@...ux-foundation.org>,
Peter Jones <pjones@...hat.com>,
"the arch/x86 maintainers" <x86@...nel.org>,
Dave Airlie <airlied@...hat.com>,
Bartlomiej Zolnierkiewicz <b.zolnierkie@...sung.com>,
"linux-fbdev@...r.kernel.org" <linux-fbdev@...r.kernel.org>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
Andrew Lutomirski <luto@...nel.org>,
Peter Anvin <hpa@...or.com>
Subject: Re: [PATCH] efifb: allow user to disable write combined mapping.
On Wed, Jul 19, 2017 at 9:07 PM, Dave Airlie <airlied@...il.com> wrote:
>
> Yes hoping someone can give some insight.
>
> Scrap the multi-socket it's been seen on a single-socket, but not as
> drastic, 2x rather than 10x slowdowns.
>
> It's starting to seem like the commonality might be the Matrox G200EH
> which is part of the HP remote management iLO hardware, it might be that
> the RAM on the other side of the PCIE connection is causing some sort of
> wierd stalls or slowdowns. I'm not sure how best to validate that either.
It shouldn't be that hard to hack up efifb to allocate some actual RAM
as "framebuffer", unmap it from the direct map, and ioremap_wc() it as
usual. Then you could see if PCIe is important for it.
WC streaming writes over PCIe end up doing 64 byte writes, right?
Maybe the Matrox chip is just extremely slow handling 64b writes.
Powered by blists - more mailing lists