On Tue, Sep 26, 2017 at 04:21:47PM +0300, Joonas Lahtinen wrote: > On Tue, 2017-09-26 at 09:52 +0200, Greg Kroah-Hartman wrote: > > On Mon, Sep 25, 2017 at 07:47:17PM +0100, Matthew Auld wrote: > > > Not a fully blown gemfs, just our very own tmpfs kernel mount. Doing so > > > moves us away from the shmemfs shm_mnt, and gives us the much needed > > > flexibility to do things like set our own mount options, namely huge= > > > which should allow us to enable the use of transparent-huge-pages for > > > our shmem backed objects. > > > > > > v2: various improvements suggested by Joonas > > > > > > v3: move gemfs instance to i915.mm and simplify now that we have > > > file_setup_with_mnt > > > > > > v4: fallback to tmpfs shm_mnt upon failure to setup gemfs > > > > > > v5: make tmpfs fallback kinder > > > > Why do this only for one specific driver? Shouldn't the drm core handle > > this for you, for all other drivers as well? Otherwise trying to figure > > out how to "contain" this type of thing is going to be a pain (mount > > options, selinux options, etc.) > > We actually started quite grande by making stripped down version of > shmemfs for drm core, but kept running into nacks about how we were > implementing it (after getting a recommendation to try implementing it > some way). After a few iterations and massive engineering time, we have > been progressively reducing the amount of changes outside i915 in the > hopes to get this merged. > > And all the while clock is ticking, so we thought the best way to get > something to support our future work is to implement this first locally > with minimal external changes outside i915 and then once we have > something working, it'll be easier to generalize it for the drm core. > Otherwise we'll never get to work with the huge page support, for which > gemfs is the stepping stone here. > > So we're not planning on sitting on top of it, we'll just incubate it > under i915/ so that it'll then be less pain for others to adopt when > the biggest hurdles with core MM interactions are sorted out. But by doing this, you are now creating a new user/kernel api that you have to support for forever, right? Will it not change if you make it "generic" to the drm core eventually? Worse case, name it a generic name that everyone will end up using in the future, and then you can just claim that all other drivers need to implement it :) thanks, greg k-h _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx
