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. -Chris -- Chris Wilson, Intel Open Source Technology Centre _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/intel-gfx
