From mboxrd@z Thu Jan 1 00:00:00 1970 From: Tvrtko Ursulin Subject: Re: [PATCH] drm/i915: Introduce mapping of user pages into video memory (userptr) ioctl Date: Mon, 03 Feb 2014 15:13:35 +0000 Message-ID: <52EFB21F.1050003@linux.intel.com> References: <1390905261-5410-4-git-send-email-chris@chris-wilson.co.uk> <1390915006-16007-1-git-send-email-chris@chris-wilson.co.uk> <20140129202551.GC11705@phenom.ffwll.local> <20140129215328.GI28110@nuc-i3427.alporthouse.com> <20140130110609.GE29091@nuc-i3427.alporthouse.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; Format="flowed" Content-Transfer-Encoding: 7bit Return-path: Received: from mga11.intel.com (mga11.intel.com [192.55.52.93]) by gabe.freedesktop.org (Postfix) with ESMTP id 15AC4F9D4F for ; Mon, 3 Feb 2014 07:13:37 -0800 (PST) In-Reply-To: <20140130110609.GE29091@nuc-i3427.alporthouse.com> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: intel-gfx-bounces@lists.freedesktop.org Errors-To: intel-gfx-bounces@lists.freedesktop.org To: Chris Wilson , Daniel Vetter , intel-gfx , Akash Goel List-Id: intel-gfx@lists.freedesktop.org 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 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