From mboxrd@z Thu Jan  1 00:00:00 1970
From: Daniel Vetter <daniel@ffwll.ch>
Subject: Re: [PATCH 2/2] drm/i915: Use remap_pfn_range() to
 prefault all PTE in a single pass
Date: Thu, 12 Jun 2014 18:15:20 +0200
Message-ID: <20140612161520.GA5821@phenom.ffwll.local>
References: <1402398881-14425-1-git-send-email-chris@chris-wilson.co.uk>
 <1402398881-14425-2-git-send-email-chris@chris-wilson.co.uk>
 <20140611211721.GB25454@bdvolkin-ubuntu-desktop>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Return-path: <intel-gfx-bounces@lists.freedesktop.org>
Received: from mail-wi0-f178.google.com (mail-wi0-f178.google.com
 [209.85.212.178])
 by gabe.freedesktop.org (Postfix) with ESMTP id 16ED56E936
 for <intel-gfx@lists.freedesktop.org>; Thu, 12 Jun 2014 09:15:27 -0700 (PDT)
Received: by mail-wi0-f178.google.com with SMTP id n15so3275639wiw.5
 for <intel-gfx@lists.freedesktop.org>; Thu, 12 Jun 2014 09:15:26 -0700 (PDT)
Content-Disposition: inline
In-Reply-To: <20140611211721.GB25454@bdvolkin-ubuntu-desktop>
List-Unsubscribe: <http://lists.freedesktop.org/mailman/options/intel-gfx>,
 <mailto:intel-gfx-request@lists.freedesktop.org?subject=unsubscribe>
List-Archive: <http://lists.freedesktop.org/archives/intel-gfx>
List-Post: <mailto:intel-gfx@lists.freedesktop.org>
List-Help: <mailto:intel-gfx-request@lists.freedesktop.org?subject=help>
List-Subscribe: <http://lists.freedesktop.org/mailman/listinfo/intel-gfx>,
 <mailto:intel-gfx-request@lists.freedesktop.org?subject=subscribe>
Errors-To: intel-gfx-bounces@lists.freedesktop.org
Sender: "Intel-gfx" <intel-gfx-bounces@lists.freedesktop.org>
To: "Volkin, Bradley D" <bradley.d.volkin@intel.com>
Cc: "intel-gfx@lists.freedesktop.org" <intel-gfx@lists.freedesktop.org>
List-Id: intel-gfx@lists.freedesktop.org

On Wed, Jun 11, 2014 at 02:17:21PM -0700, Volkin, Bradley D wrote:
> On Tue, Jun 10, 2014 at 04:14:41AM -0700, Chris Wilson wrote:
> > On an Ivybridge i7-3720qm with 1600MHz DDR3, with 32 fences,
> > Upload rate for 2 linear surfaces:  8134MiB/s -> 8154MiB/s
> > Upload rate for 2 tiled surfaces:   8625MiB/s -> 8632MiB/s
> > Upload rate for 4 linear surfaces:  8127MiB/s -> 8134MiB/s
> > Upload rate for 4 tiled surfaces:   8602MiB/s -> 8629MiB/s
> > Upload rate for 8 linear surfaces:  8124MiB/s -> 8137MiB/s
> > Upload rate for 8 tiled surfaces:   8603MiB/s -> 8624MiB/s
> > Upload rate for 16 linear surfaces: 8123MiB/s -> 8128MiB/s
> > Upload rate for 16 tiled surfaces:  8606MiB/s -> 8618MiB/s
> > Upload rate for 32 linear surfaces: 8121MiB/s -> 8128MiB/s
> > Upload rate for 32 tiled surfaces:  8605MiB/s -> 8614MiB/s
> > Upload rate for 64 linear surfaces: 8121MiB/s -> 8127MiB/s
> > Upload rate for 64 tiled surfaces:  3017MiB/s -> 5127MiB/s
> > 
> > Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
> 
> The translation from vm_insert_pfn to remap_pfn_range looks correct. I don't know
> these APIs particularly well though. I wonder if there's any reason it would be
> unsafe to call remap_pfn_range from .fault() since it seems to only be used in
> .mmap() handlers in other places. Reading their implementations, nothing jumped
> out, so I'll say

So apparently wasn't quite the same semantics and remap_pfn_range doesn't
handle concurrent operations too well. Can you please also review Chris'
fixup patch for that?

Thanks, Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch