[Intel-gfx] [PATCH 18/18] drm/i915: Introduce mapping of user pages into video memory (userptr) ioctl

[Daniel Vetter]

On Tue, Oct 23, 2012 at 12:21 AM, Jesse Barnes <jbarnes at virtuousgeek.org> wrote:
> On Fri, 19 Oct 2012 18:03:24 +0100
> Chris Wilson <chris at chris-wilson.co.uk> 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