From mboxrd@z Thu Jan 1 00:00:00 1970 From: Daniel Vetter Subject: Re: [PATCH 18/18] drm/i915: Introduce mapping of user pages into video memory (userptr) ioctl Date: Tue, 23 Oct 2012 09:20:50 +0200 Message-ID: References: <1350666204-8101-1-git-send-email-chris@chris-wilson.co.uk> <1350666204-8101-18-git-send-email-chris@chris-wilson.co.uk> <20121022152110.6c983c10@jbarnes-desktop> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from mail-wi0-f171.google.com (mail-wi0-f171.google.com [209.85.212.171]) by gabe.freedesktop.org (Postfix) with ESMTP id 165549E7B0 for ; Tue, 23 Oct 2012 00:20:51 -0700 (PDT) Received: by mail-wi0-f171.google.com with SMTP id hj13so2505721wib.12 for ; Tue, 23 Oct 2012 00:20:51 -0700 (PDT) In-Reply-To: <20121022152110.6c983c10@jbarnes-desktop> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: intel-gfx-bounces+gcfxdi-intel-gfx=m.gmane.org@lists.freedesktop.org Errors-To: intel-gfx-bounces+gcfxdi-intel-gfx=m.gmane.org@lists.freedesktop.org To: Jesse Barnes Cc: intel-gfx@lists.freedesktop.org List-Id: intel-gfx@lists.freedesktop.org On Tue, Oct 23, 2012 at 12:21 AM, Jesse Barnes wrote: > On Fri, 19 Oct 2012 18:03:24 +0100 > Chris Wilson wrote: > >> By exporting the ability to map user address and inserting PTEs >> representing their backing pages into the GTT, we can exploit UMA in order >> to utilize normal application data as a texture source or even as a >> render target (depending upon the capabilities of the chipset). This has >> a number of uses, with zero-copy downloads to the GPU and efficient >> readback making the intermixed streaming of CPU and GPU operations >> fairly efficient. This ability has many widespread implications from >> faster rendering of client-side software rasterisers (chromium), >> mitigation of stalls due to read back (firefox) and to faster pipelining >> of texture data (such as pixel buffer objects in GL). >> >> v2: Compile with CONFIG_MMU_NOTIFIER > > I want to understand the root-only nature of this better. > > Is locking complexity the only reason we can't treat these pages like > normal BOs which can be swapped out from under us as long as they're > not pinned into the GTT? Or are there other complications in managing > the refcount for these pages? Essentially the complication in pinning tons of memory that we don't control, and hence might upset other kernel mm parts (like page migration). For native objects we can always fix this by intercepting more of the vm callbacks for the shmem backing storage (i.e. gemfs). But for foreing storage we need to use the mmu_notifiers, and atm those expect that a pte shootdown is synchronous (which we can't do), so there's some work left to get done imo. > Reminds me: do we also check our bo allocations against the current > task's address space, data, file size, locked memory, file count, > and rss limits? I dug into the shmem code at one point and seem to > remember that we didn't. If not, it might be a good thing to add under > a new config option at some point. Nope, we don't limit nor properly track userspace bo allocations. If we run up against the OOM killer, it tends to kill everything _but_ the gem process hogging a few GB, since all those allocations are not associated with a process (e.g. for execbuf or for gtt mmaps, cpu shmem mmaps should account properly). -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch