From: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
To: Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
Matthew Auld <matthew.auld@intel.com>
Cc: intel-gfx@lists.freedesktop.org, devel@driverdev.osuosl.org,
linux-mm@kvack.org, "Hugh Dickins" <hughd@google.com>,
"Riley Andrews" <riandrews@android.com>,
dri-devel@lists.freedesktop.org,
"Chris Wilson" <chris@chris-wilson.co.uk>,
"Dave Hansen" <dave.hansen@intel.com>,
"Arve Hjønnevåg" <arve@android.com>,
"Kirill A . Shutemov" <kirill@shutemov.name>,
"Daniel Vetter" <daniel.vetter@intel.com>,
"Andrew Morton" <akpm@linux-foundation.org>
Subject: Re: [PATCH 02/22] drm/i915: introduce simple gemfs
Date: Tue, 26 Sep 2017 16:21:47 +0300 [thread overview]
Message-ID: <1506432107.5228.26.camel@linux.intel.com> (raw)
In-Reply-To: <20170926075221.GB32088@kroah.com>
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.
Regards, Joonas
--
Joonas Lahtinen
Open Source Technology Center
Intel Corporation
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
next prev parent reply other threads:[~2017-09-26 13:22 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20170925184737.8807-1-matthew.auld@intel.com>
2017-09-25 18:47 ` [PATCH 01/22] mm/shmem: support passing mnt to shmem_file_setup Matthew Auld
2017-09-25 18:47 ` [PATCH 02/22] drm/i915: introduce simple gemfs Matthew Auld
2017-09-26 7:52 ` Greg Kroah-Hartman
2017-09-26 13:21 ` Joonas Lahtinen [this message]
2017-09-26 21:34 ` Greg Kroah-Hartman
2017-09-27 7:50 ` Joonas Lahtinen
2017-09-25 18:47 ` [PATCH 03/22] mm/shmem: parse mount options for MS_KERNMOUNT Matthew Auld
2017-09-25 19:28 ` Chris Wilson
2017-09-25 18:47 ` [PATCH 04/22] drm/i915/gemfs: enable THP Matthew Auld
2017-09-25 19:11 ` Chris Wilson
[not found] <20170815181215.18310-1-matthew.auld@intel.com>
2017-08-15 18:11 ` [PATCH 02/22] drm/i915: introduce simple gemfs Matthew Auld
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1506432107.5228.26.camel@linux.intel.com \
--to=joonas.lahtinen@linux.intel.com \
--cc=akpm@linux-foundation.org \
--cc=arve@android.com \
--cc=chris@chris-wilson.co.uk \
--cc=daniel.vetter@intel.com \
--cc=dave.hansen@intel.com \
--cc=devel@driverdev.osuosl.org \
--cc=dri-devel@lists.freedesktop.org \
--cc=gregkh@linuxfoundation.org \
--cc=hughd@google.com \
--cc=intel-gfx@lists.freedesktop.org \
--cc=kirill@shutemov.name \
--cc=linux-mm@kvack.org \
--cc=matthew.auld@intel.com \
--cc=riandrews@android.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).