Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
        id S933051AbdGTE2v (ORCPT <rfc822;w@1wt.eu>);
        Thu, 20 Jul 2017 00:28:51 -0400
Received: from mail.kernel.org ([198.145.29.99]:58876 "EHLO mail.kernel.org"
        rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP
        id S932195AbdGTE2t (ORCPT <rfc822;linux-kernel@vger.kernel.org>);
        Thu, 20 Jul 2017 00:28:49 -0400
DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org B44EC22C9B
Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=kernel.org
Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=luto@kernel.org
MIME-Version: 1.0
In-Reply-To: <CAPM=9tx0CytpjmYy2r1fdiG-KcZUXmxVQKWDAfiLcAfE=ZT7dQ@mail.gmail.com>
References: <20170718060909.5280-1-airlied@redhat.com> <20170718143404.omgxrujngj2rhiya@redhat.com>
 <CA+55aFwKzwDPYFsPpuQNfBaS-dL2aD0=z1hGEnkaTT1MMfWB6Q@mail.gmail.com>
 <CAPM=9tyWv79U9=-YNacf34don_Gn5RGggBsZG7R9FNuV8_qe1g@mail.gmail.com>
 <CAPM=9twtiyJb2M3tBBb6Xy3ausVxhn3Be+NTr+BAV9FTMGPkug@mail.gmail.com>
 <CA+55aFyU3QrFeq4Lr9tgxR+6D9-eXZFZTzfqHdozHS72qE5q1w@mail.gmail.com>
 <CAPM=9twzgAJir3b+3UAxOfuTtOBTp2bUtoCcTawmHcEbcVAEew@mail.gmail.com>
 <CAPM=9twsWFjFcgjP6S4wt7-t9-wYP_gBH1zt6kL-CF4Tr7t2dg@mail.gmail.com>
 <CAPM=9tyE88nz92e252vqgoqAK+OUut3EZKzTu9L8nwLE_hLQkQ@mail.gmail.com>
 <CA+55aFz7+_DsGRk1weqBNcX6GavK6rUUMSk5oaSbt4yp=EGt=Q@mail.gmail.com> <CAPM=9tx0CytpjmYy2r1fdiG-KcZUXmxVQKWDAfiLcAfE=ZT7dQ@mail.gmail.com>
From: Andy Lutomirski <luto@kernel.org>
Date: Wed, 19 Jul 2017 21:28:27 -0700
X-Gmail-Original-Message-ID: <CALCETrWFe+qSC9r+waf3XH-9XcrtfRMtG3AL6ndgG4PQ4QdPHQ@mail.gmail.com>
Message-ID: <CALCETrWFe+qSC9r+waf3XH-9XcrtfRMtG3AL6ndgG4PQ4QdPHQ@mail.gmail.com>
Subject: Re: [PATCH] efifb: allow user to disable write combined mapping.
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>
Content-Type: text/plain; charset="UTF-8"
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org
Content-Length: 864
Lines: 18

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.