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@xxxxxxxxxxxxxxxxxx> 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
_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
