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@xxxxxxxxx>
> Cc: Joonas Lahtinen <joonas.lahtinen@xxxxxxxxxxxxxxx>
> Cc: Chris Wilson <chris@xxxxxxxxxxxxxxxxxx>
<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@xxxxxxxxxxxxxxx>
Regards, Joonas
--
Joonas Lahtinen
Open Source Technology Center
Intel Corporation
_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
