Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752651AbdGSAAz (ORCPT ); Tue, 18 Jul 2017 20:00:55 -0400 Received: from mail-vk0-f51.google.com ([209.85.213.51]:34901 "EHLO mail-vk0-f51.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752585AbdGSAAx (ORCPT ); Tue, 18 Jul 2017 20:00:53 -0400 MIME-Version: 1.0 In-Reply-To: References: <20170718060909.5280-1-airlied@redhat.com> <20170718143404.omgxrujngj2rhiya@redhat.com> From: Dave Airlie Date: Wed, 19 Jul 2017 10:00:51 +1000 Message-ID: Subject: Re: [PATCH] efifb: allow user to disable write combined mapping. To: Linus Torvalds Cc: Peter Jones , "the arch/x86 maintainers" , Dave Airlie , Bartlomiej Zolnierkiewicz , "linux-fbdev@vger.kernel.org" , Linux Kernel Mailing List , Andrew Lutomirski , Peter Anvin Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2433 Lines: 58 On 19 July 2017 at 09:16, Dave Airlie wrote: > On 19 July 2017 at 09:16, Dave Airlie wrote: >> On 19 July 2017 at 08:22, Linus Torvalds wrote: >>> On Tue, Jul 18, 2017 at 2:21 PM, Dave Airlie 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. > More digging: Single CPU system: Intel(R) Xeon(R) CPU E5-2620 v2 @ 2.10GHz 01:00.1 VGA compatible controller: Matrox Electronics Systems Ltd. MGA G200EH Now I can't get efifb to load on this (due to it being remote and I've no idea how to make my install efi onto it), but booting with no framebuffer, and running the tests on the mga, show no slowdown on this. Now I'm starting to wonder if it's something that only happens on multi-socket systems. Dave.