All of lore.kernel.org
 help / color / mirror / Atom feed
From: Dave Airlie <airlied@gmail.com>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: 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: Wed, 19 Jul 2017 09:16:17 +1000	[thread overview]
Message-ID: <CAPM=9twzgAJir3b+3UAxOfuTtOBTp2bUtoCcTawmHcEbcVAEew@mail.gmail.com> (raw)
In-Reply-To: <CA+55aFyU3QrFeq4Lr9tgxR+6D9-eXZFZTzfqHdozHS72qE5q1w@mail.gmail.com>

On 19 July 2017 at 08:22, Linus Torvalds <torvalds@linux-foundation.org> wrote:
> On Tue, Jul 18, 2017 at 2:21 PM, Dave Airlie <airlied@gmail.com> wrote:
>>
>> Oh and just FYI, the machine I've tested this on has an mgag200 server
>> graphics card backing the framebuffer, but with just efifb loaded.
>
> Yeah, it looks like it needs special hardware - and particularly the
> kind of garbage hardware that people only have on servers.
>
> Why do server people continually do absolute sh*t hardware? It's crap,
> crap, crap across the board outside the CPU. Nasty and bad hacky stuff
> that nobody else would touch with a ten-foot pole, and the "serious
> enterprise" people lap it up like it was ambrosia.
>
> It's not just "graphics is bad anyway since we don't care". It's all
> the things they ostensibly _do_ care about too, like the disk and the
> fabric infrastructure. Buggy nasty crud.

I've tried to reproduce now on:
Intel(R) Core(TM) i7-6820HQ CPU @ 2.70GHz
using some address space from
02:00.0 3D controller: NVIDIA Corporation GM108M [GeForce 940MX] (rev a2)

And I don't see the issue.

I'll try and track down some more efi compatible mga or other wierd server chips
stuff if I can.

> Anyway, rant over. I wonder if we could show this without special
> hardware by just mapping some region that doesn't even have hardware
> in it as WC. Do we even expose the PAT settings to user space, though,
> or do we always have to have some fake module to create the PAT stuff?

I do wonder wtf the hw could be doing that would cause this, but I've no idea
how to tell what difference a write combined PCI transaction would have on the
bus side of things, and what the device could generate that would cause such
a horrible slowdown.

Dave.

WARNING: multiple messages have this Message-ID (diff)
From: Dave Airlie <airlied@gmail.com>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: 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: Tue, 18 Jul 2017 23:16:17 +0000	[thread overview]
Message-ID: <CAPM=9twzgAJir3b+3UAxOfuTtOBTp2bUtoCcTawmHcEbcVAEew@mail.gmail.com> (raw)
In-Reply-To: <CA+55aFyU3QrFeq4Lr9tgxR+6D9-eXZFZTzfqHdozHS72qE5q1w@mail.gmail.com>

On 19 July 2017 at 08:22, Linus Torvalds <torvalds@linux-foundation.org> wrote:
> On Tue, Jul 18, 2017 at 2:21 PM, Dave Airlie <airlied@gmail.com> wrote:
>>
>> Oh and just FYI, the machine I've tested this on has an mgag200 server
>> graphics card backing the framebuffer, but with just efifb loaded.
>
> Yeah, it looks like it needs special hardware - and particularly the
> kind of garbage hardware that people only have on servers.
>
> Why do server people continually do absolute sh*t hardware? It's crap,
> crap, crap across the board outside the CPU. Nasty and bad hacky stuff
> that nobody else would touch with a ten-foot pole, and the "serious
> enterprise" people lap it up like it was ambrosia.
>
> It's not just "graphics is bad anyway since we don't care". It's all
> the things they ostensibly _do_ care about too, like the disk and the
> fabric infrastructure. Buggy nasty crud.

I've tried to reproduce now on:
Intel(R) Core(TM) i7-6820HQ CPU @ 2.70GHz
using some address space from
02:00.0 3D controller: NVIDIA Corporation GM108M [GeForce 940MX] (rev a2)

And I don't see the issue.

I'll try and track down some more efi compatible mga or other wierd server chips
stuff if I can.

> Anyway, rant over. I wonder if we could show this without special
> hardware by just mapping some region that doesn't even have hardware
> in it as WC. Do we even expose the PAT settings to user space, though,
> or do we always have to have some fake module to create the PAT stuff?

I do wonder wtf the hw could be doing that would cause this, but I've no idea
how to tell what difference a write combined PCI transaction would have on the
bus side of things, and what the device could generate that would cause such
a horrible slowdown.

Dave.

  reply	other threads:[~2017-07-18 23:16 UTC|newest]

Thread overview: 38+ 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  6:09 ` Dave Airlie
2017-07-18 14:34 ` Peter Jones
2017-07-18 14:34   ` Peter Jones
2017-07-18 19:57   ` Linus Torvalds
2017-07-18 19:57     ` Linus Torvalds
2017-07-18 20:44     ` Dave Airlie
2017-07-18 20:44       ` Dave Airlie
2017-07-18 21:21       ` Dave Airlie
2017-07-18 21:21         ` Dave Airlie
2017-07-18 22:22         ` Linus Torvalds
2017-07-18 22:22           ` Linus Torvalds
2017-07-18 23:16           ` Dave Airlie [this message]
2017-07-18 23:16             ` Dave Airlie
2017-07-18 23:16             ` Dave Airlie
2017-07-18 23:16               ` Dave Airlie
2017-07-19  0:00               ` Dave Airlie
2017-07-19  0:00                 ` Dave Airlie
2017-07-19  1:15                 ` Linus Torvalds
2017-07-19  1:15                   ` Linus Torvalds
2017-07-20  4:07                   ` Dave Airlie
2017-07-20  4:07                     ` Dave Airlie
2017-07-20  4:28                     ` Andy Lutomirski
2017-07-20  4:28                       ` Andy Lutomirski
2017-07-20  4:44                       ` Linus Torvalds
2017-07-20  4:44                         ` Linus Torvalds
2017-07-21  4:27                         ` Dave Airlie
2017-07-21  4:27                           ` Dave Airlie
2017-07-20 10:20           ` Ingo Molnar
2017-07-20 10:20             ` Ingo Molnar
2017-07-31 19:13       ` H. Peter Anvin
2017-07-31 19:13         ` H. Peter Anvin
2017-07-25  4:00   ` Dave Airlie
2017-07-25  4:00     ` Dave Airlie
2017-07-25  8:56     ` Bartlomiej Zolnierkiewicz
2017-07-25  8:56       ` Bartlomiej Zolnierkiewicz
     [not found]       ` <CGME20170731171022epcas1p2c5537a0a79eca05a729773d4cabaac27@epcas1p2.samsung.com>
2017-07-31 17:10         ` Bartlomiej Zolnierkiewicz
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='CAPM=9twzgAJir3b+3UAxOfuTtOBTp2bUtoCcTawmHcEbcVAEew@mail.gmail.com' \
    --to=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=luto@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.