On 29 August 2017 at 15:49, Joonas Lahtinen
<joonas.lahtinen@xxxxxxxxxxxxxxx> 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@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[] ?
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@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
_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
