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

[Tvrtko Ursulin]

On 01/30/2014 11:06 AM, Chris Wilson wrote:
> On Wed, Jan 29, 2014 at 10:58:48PM +0100, Daniel Vetter wrote:
>> On Wed, Jan 29, 2014 at 10:53 PM, Chris Wilson <chris at chris-wilson.co.uk> wrote:
>>> On Wed, Jan 29, 2014 at 09:25:51PM +0100, Daniel Vetter wrote:
>>>> So originally I've thought we need this due to the massive overhead of the
>>>> mmu notifier. But now with the nice shared mmu notifiers I've thought that
>>>> overhead is gone I prefer to also ditch this option.
>>>>
>>>> Same goes about the MMU_NOTIFIER conditional code, imo we simply should
>>>> select this - most distros will have it anyway and users will be really
>>>> suprised if they lose userspace driver features for seemingly irrelevant
>>>> reasons.
>>>
>>> Seriously? You think the overhead is magically gone?
>>
>> Well the once-per-process overhead is still there, and imo it's ok to
>> eat that. But the complaints I've heard concerned the per-object
>> overhead, so I wonder how much of that is still relevant.
>
> I am still annoyed by the thought of having to enable an extra feature
> in my kernels, and the extra code that is then run on every mm
> operation. (Mixing mmu_notifiers + mm debuging was an especially
> unpleasant experience that I don't wish to ever do again.)
>
> Numbers talk though, if we can't demonstrate a significant difference
> between the two, it can die. Keeping a debug mode to turn off
> mmu_notifiers would still be good so that we can keep track of any
> impact over time.

Writing a benchmark for this is next on my userptr to do list following 
completing of the i-g-t test case.

Btw, I did not notice you are discussing this sooner since I got dropped 
from Cc. Only when Rafael mentioned he saw some discussion about 
potential exploit I went looking.

Tvrtko