Received: by 2002:ac0:a5a7:0:0:0:0:0 with SMTP id m36-v6csp886073imm; Wed, 8 Aug 2018 07:23:04 -0700 (PDT) X-Google-Smtp-Source: AA+uWPwPD0A61lGJU/0J1jVkOswUGrHOKAfjxekSZqxO3lMnbX8DNlbElZ5HnFkvSIe1Qn9XMW0K X-Received: by 2002:a62:c505:: with SMTP id j5-v6mr3133292pfg.153.1533738184292; Wed, 08 Aug 2018 07:23:04 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1533738184; cv=none; d=google.com; s=arc-20160816; b=EMubirCk6/uigd0WGqevCvx51+hHpPlCJb9RYQeVkEl5UQUCgWRB8ikq4/mlaVHfPr Fk7kZe0OI9dZtJ2IDSHQqA/MrRzU9HmxOo09F5DBFqA9OcvAf9n00VWCGM+cONuEwvc8 WUOs4+XAcZZ2AqQPfTke7XF0cUvWJ5cjs2bUDRFdiVgMOU3adOSgLengelTdk3cvtEQW i1ntnfartWKAXPLgxS4+LLcJuVTVmJ/ljteV962qZOzt5OM1NmMDse97La5F5wG1XiDb KULnt88cfI2J8siWLS1bKqo+9U0xtQwUnyMrc21IOxBoKQAgMN13/RKbqMXrO7ixBLdN KvmQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:mime-version:user-agent:references :message-id:in-reply-to:subject:cc:to:from:date :arc-authentication-results; bh=e5zRdHTKihxrsfkJZ8HKNNInDO7F72yV1d241c2ncuI=; b=nIretVgeNQglC6m3oYuo3q7fAEDe+wUPvs14CwcMwemIz/I2kN3axC3t0CMjyZ0nQx 3ka0exu4p6aRm8dxTSGhtnIs8XPqBvNWBk+F/5u2LElMW+UzfEkdQZTw/Yio+gW6Gh8X 7WFgxOexIeucykTUy2fj5PHE+NZvIvBNr1AlE+bNBtkHjetwmx7wPEDx9/M9tXISXhcD PgJyxUP1ASpB5MgKmkfzJrT/BQK4JBOHztx47V66xWHw/c0pVs1czbbRo1RkZF5GbahJ Pot0D+tfWczmZwm9f8rW7pLyI6t00czc5AK+47iYD9GOEg/U0fXqzEBTmcZCyjvACna0 twZQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=redhat.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id z137-v6si3662751pgz.144.2018.08.08.07.22.48; Wed, 08 Aug 2018 07:23:04 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727483AbeHHQll (ORCPT + 99 others); Wed, 8 Aug 2018 12:41:41 -0400 Received: from mx3-rdu2.redhat.com ([66.187.233.73]:48084 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1727109AbeHHQll (ORCPT ); Wed, 8 Aug 2018 12:41:41 -0400 Received: from smtp.corp.redhat.com (int-mx04.intmail.prod.int.rdu2.redhat.com [10.11.54.4]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 80F44402315B; Wed, 8 Aug 2018 14:21:47 +0000 (UTC) Received: from file01.intranet.prod.int.rdu2.redhat.com (file01.intranet.prod.int.rdu2.redhat.com [10.11.5.7]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 3267420180F4; Wed, 8 Aug 2018 14:21:47 +0000 (UTC) Received: from file01.intranet.prod.int.rdu2.redhat.com (localhost [127.0.0.1]) by file01.intranet.prod.int.rdu2.redhat.com (8.14.4/8.14.4) with ESMTP id w78ELlJ5011795; Wed, 8 Aug 2018 10:21:47 -0400 Received: from localhost (mpatocka@localhost) by file01.intranet.prod.int.rdu2.redhat.com (8.14.4/8.14.4/Submit) with ESMTP id w78ELkNR011791; Wed, 8 Aug 2018 10:21:46 -0400 X-Authentication-Warning: file01.intranet.prod.int.rdu2.redhat.com: mpatocka owned process doing -bs Date: Wed, 8 Aug 2018 10:21:46 -0400 (EDT) From: Mikulas Patocka X-X-Sender: mpatocka@file01.intranet.prod.int.rdu2.redhat.com To: David Laight cc: "'Ard Biesheuvel'" , Ramana Radhakrishnan , Florian Weimer , Thomas Petazzoni , GNU C Library , Andrew Pinski , Catalin Marinas , Will Deacon , Russell King , LKML , linux-arm-kernel Subject: RE: framebuffer corruption due to overlapping stp instructions on arm64 In-Reply-To: <5f5ab5ba0bc84b31be52bd7708c6a356@AcuMS.aculab.com> Message-ID: References: <9acdacdb-3bd5-b71a-3003-e48132ee1371@redhat.com> <51a6c4e102ad4193b3f42498f0ff11a4@AcuMS.aculab.com> <5f5ab5ba0bc84b31be52bd7708c6a356@AcuMS.aculab.com> User-Agent: Alpine 2.02 (LRH 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Scanned-By: MIMEDefang 2.78 on 10.11.54.4 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.11.55.6]); Wed, 08 Aug 2018 14:21:47 +0000 (UTC) X-Greylist: inspected by milter-greylist-4.5.16 (mx1.redhat.com [10.11.55.6]); Wed, 08 Aug 2018 14:21:47 +0000 (UTC) for IP:'10.11.54.4' DOMAIN:'int-mx04.intmail.prod.int.rdu2.redhat.com' HELO:'smtp.corp.redhat.com' FROM:'mpatocka@redhat.com' RCPT:'' Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, 7 Aug 2018, David Laight wrote: > From: Mikulas Patocka > > Sent: 07 August 2018 15:07 > ... > > Unaccelerated scrolling is still painfully slow > > even on modern computers because of slow framebuffer read. > > I solved that many years ago on a strongarm system by mapping > the screen memory at two separate virtual addresses. > One uncached used for writes, the second cached using the > 'minicache' for reads. > (and immediately fell foul of a memcpy() function that compared > the two virtual addresses and decided to copy backwards) > > I suspect some modern cpus don't like you doing that and the > graphics 'drivers' won't use different mappings. Intel says that you can't mix PAT memory attributes - but the non-temporal store instructions use write-combining semantics on a memory that is normally cacheable - and it is allowed to mix non-temporal stores with other cacheable memory accesses - so I believe that the CPU will snoop the cache for wc accesses and handle the conflict. > Even in glibc you want a more general copy_to/from_io_memory() > rather than just 'copy_from_framebuffer()'. > Best to define both - even if they end up identical. > Other drivers allow PCIe space be mmap()ed into user space. > > While your tests show vmovntdqa being slightly slower than an > avx read for uncached mappings it is still much better than > all the other options. Tihs was a measuring glitch - movntdqa is as fast as movdqa on non-cached mappings. Mikulas > David > > - > Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK > Registration No: 1397386 (Wales) >