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.
next prev parent 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: linkBe 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.