From: Andy Lutomirski <luto@kernel.org>
To: Dave Airlie <airlied@gmail.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>,
Peter Jones <pjones@redhat.com>,
the arch/x86 maintainers <x86@kernel.org>,
Dave Airlie <airlied@redhat.com>,
Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>,
"linux-fbdev@vger.kernel.org" <linux-fbdev@vger.kernel.org>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
Andrew Lutomirski <luto@kernel.org>, Peter Anvin <hpa@zytor.com>
Subject: Re: [PATCH] efifb: allow user to disable write combined mapping.
Date: Thu, 20 Jul 2017 04:28:27 +0000 [thread overview]
Message-ID: <CALCETrWFe+qSC9r+waf3XH-9XcrtfRMtG3AL6ndgG4PQ4QdPHQ@mail.gmail.com> (raw)
In-Reply-To: <CAPM=9tx0CytpjmYy2r1fdiG-KcZUXmxVQKWDAfiLcAfE=ZT7dQ@mail.gmail.com>
On Wed, Jul 19, 2017 at 9:07 PM, Dave Airlie <airlied@gmail.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.
next prev parent reply other threads:[~2017-07-20 4:28 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-07-18 6:09 [PATCH] efifb: allow user to disable write combined mapping Dave Airlie
2017-07-18 14:34 ` Peter Jones
2017-07-18 19:57 ` Linus Torvalds
2017-07-18 20:44 ` Dave Airlie
2017-07-18 21:21 ` Dave Airlie
2017-07-18 22:22 ` Linus Torvalds
2017-07-18 23:16 ` Dave Airlie
2017-07-18 23:16 ` Dave Airlie
2017-07-19 0:00 ` Dave Airlie
2017-07-19 1:15 ` Linus Torvalds
2017-07-20 4:07 ` Dave Airlie
2017-07-20 4:28 ` Andy Lutomirski [this message]
2017-07-20 4:44 ` Linus Torvalds
2017-07-21 4:27 ` Dave Airlie
2017-07-20 10:20 ` Ingo Molnar
2017-07-31 19:13 ` H. Peter Anvin
2017-07-25 4:00 ` Dave Airlie
2017-07-25 8:56 ` Bartlomiej Zolnierkiewicz
[not found] ` <CGME20170731171022epcas1p2c5537a0a79eca05a729773d4cabaac27@epcas1p2.samsung.com>
2017-07-31 17:10 ` Bartlomiej Zolnierkiewicz
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=CALCETrWFe+qSC9r+waf3XH-9XcrtfRMtG3AL6ndgG4PQ4QdPHQ@mail.gmail.com \
--to=luto@kernel.org \
--cc=airlied@gmail.com \
--cc=airlied@redhat.com \
--cc=b.zolnierkie@samsung.com \
--cc=hpa@zytor.com \
--cc=linux-fbdev@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=pjones@redhat.com \
--cc=torvalds@linux-foundation.org \
--cc=x86@kernel.org \
/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).