| Message ID | 20170821183503.12246-4-matthew.auld@intel.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
On Mon, 2017-08-21 at 19:34 +0100, Matthew Auld wrote: > Enable transparent-huge-pages through gemfs by mounting with > huge=within_size. > > Signed-off-by: Matthew Auld <matthew.auld@intel.com> > Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> > Cc: Chris Wilson <chris@chris-wilson.co.uk> <SNIP> > +++ b/drivers/gpu/drm/i915/i915_gemfs.c > @@ -24,6 +24,7 @@ > > #include <linux/fs.h> > #include <linux/mount.h> > +#include <linux/pagemap.h> > > #include "i915_drv.h" > #include "i915_gemfs.h" > @@ -41,6 +42,20 @@ int i915_gemfs_init(struct drm_i915_private *i915) > if (IS_ERR(gemfs)) > return PTR_ERR(gemfs); > > + if (has_transparent_hugepage()) { > + struct super_block *sb = gemfs->mnt_sb; > + char options[] = "huge=within_size"; char const options[] ? > + int flags = 0; > + > + /* We don't consider failure to remount fatal, since this should > + * only ever attempt to modify the mount options of the sb, and > + * so should always leave us with a working mount upon failure. > + * Hence decoupling this from the actual kern_mount is probably > + * advisable. > + */ > + WARN_ON(sb->s_op->remount_fs(sb, &flags, options)); Not to have too many fallback paths, would it make sense for any error in setting up gemfs to result in NULL gemfs and fallback to tmpfs? With the string constified, this is: Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Regards, Joonas
On 29 August 2017 at 15:49, Joonas Lahtinen <joonas.lahtinen@linux.intel.com> wrote: > On Mon, 2017-08-21 at 19:34 +0100, Matthew Auld wrote: >> Enable transparent-huge-pages through gemfs by mounting with >> huge=within_size. >> >> Signed-off-by: Matthew Auld <matthew.auld@intel.com> >> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> >> Cc: Chris Wilson <chris@chris-wilson.co.uk> > > <SNIP> > >> +++ b/drivers/gpu/drm/i915/i915_gemfs.c >> @@ -24,6 +24,7 @@ >> >> #include <linux/fs.h> >> #include <linux/mount.h> >> +#include <linux/pagemap.h> >> >> #include "i915_drv.h" >> #include "i915_gemfs.h" >> @@ -41,6 +42,20 @@ int i915_gemfs_init(struct drm_i915_private *i915) >> if (IS_ERR(gemfs)) >> return PTR_ERR(gemfs); >> >> + if (has_transparent_hugepage()) { >> + struct super_block *sb = gemfs->mnt_sb; >> + char options[] = "huge=within_size"; > > char const options[] ? remount_fs expects char *data, and shmem_parse_options() may try to modify data. > >> + int flags = 0; >> + >> + /* We don't consider failure to remount fatal, since this should >> + * only ever attempt to modify the mount options of the sb, and >> + * so should always leave us with a working mount upon failure. >> + * Hence decoupling this from the actual kern_mount is probably >> + * advisable. >> + */ >> + WARN_ON(sb->s_op->remount_fs(sb, &flags, options)); > > Not to have too many fallback paths, would it make sense for any error > in setting up gemfs to result in NULL gemfs and fallback to tmpfs? Okay, will do. > > With the string constified, this is: > > Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> > > Regards, Joonas > -- > Joonas Lahtinen > Open Source Technology Center > Intel Corporation > _______________________________________________ > Intel-gfx mailing list > Intel-gfx@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/intel-gfx
diff --git a/drivers/gpu/drm/i915/i915_gemfs.c b/drivers/gpu/drm/i915/i915_gemfs.c index 168d0bd98f60..999f0b6a2d64 100644 --- a/drivers/gpu/drm/i915/i915_gemfs.c +++ b/drivers/gpu/drm/i915/i915_gemfs.c @@ -24,6 +24,7 @@ #include <linux/fs.h> #include <linux/mount.h> +#include <linux/pagemap.h> #include "i915_drv.h" #include "i915_gemfs.h" @@ -41,6 +42,20 @@ int i915_gemfs_init(struct drm_i915_private *i915) if (IS_ERR(gemfs)) return PTR_ERR(gemfs); + if (has_transparent_hugepage()) { + struct super_block *sb = gemfs->mnt_sb; + char options[] = "huge=within_size"; + int flags = 0; + + /* We don't consider failure to remount fatal, since this should + * only ever attempt to modify the mount options of the sb, and + * so should always leave us with a working mount upon failure. + * Hence decoupling this from the actual kern_mount is probably + * advisable. + */ + WARN_ON(sb->s_op->remount_fs(sb, &flags, options)); + } + i915->mm.gemfs = gemfs; return 0;
Enable transparent-huge-pages through gemfs by mounting with huge=within_size. Signed-off-by: Matthew Auld <matthew.auld@intel.com> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> --- drivers/gpu/drm/i915/i915_gemfs.c | 15 +++++++++++++++ 1 file changed, 15 insertions(+)