drm/i915: Stop reconfiguring our shmemfs mountpoint

The filesystem reconfigure API is undergoing a transition, breaking our
current code. As we only set the default options, we can simply remove
the call to s_op->remount_fs(). In the future, when HW permits, we can
try re-enabling huge page support, albeit as suggested with new per-file
controls.

Reported-by: Sergey Senozhatsky <[e-mail]>
Reported-by: Sedat Dilek <[e-mail]>
Suggested-by: Hugh Dickins <[e-mail]>
Signed-off-by: Chris Wilson <[e-mail]>
Cc: Matthew Auld <[e-mail]>
Cc: Hugh Dickins <[e-mail]>
Cc: Al Viro <[e-mail]>
Cc: Sergey Senozhatsky <[e-mail]>
Reviewed-by: Matthew Auld <[e-mail]>
Link: https://patchwork.freedesktop.org/patch/msgid/[e-mail]

drivers/gpu/drm/i915/gem/i915_gemfs.c

···
 	if (!type)
 		return -ENODEV;
 
+	/*
+	 * By creating our own shmemfs mountpoint, we can pass in
+	 * mount flags that better match our usecase.
+	 *
+	 * One example, although it is probably better with a per-file
+	 * control, is selecting huge page allocations ("huge=within_size").
+	 * Currently unused due to bandwidth issues (slow reads) on Broadwell+.
+	 */
+
 	gemfs = kern_mount(type);
 	if (IS_ERR(gemfs))
 		return PTR_ERR(gemfs);
-
-	/*
-	 * Enable huge-pages for objects that are at least HPAGE_PMD_SIZE, most
-	 * likely 2M. Note that within_size may overallocate huge-pages, if say
-	 * we allocate an object of size 2M + 4K, we may get 2M + 2M, but under
-	 * memory pressure shmem should split any huge-pages which can be
-	 * shrunk.
-	 */
-
-	if (has_transparent_hugepage()) {
-		struct super_block *sb = gemfs->mnt_sb;
-		/* FIXME: Disabled until we get W/A for read BW issue. */
-		char options[] = "huge=never";
-		int flags = 0;
-		int err;
-
-		err = sb->s_op->remount_fs(sb, &flags, options);
-		if (err) {
-			kern_unmount(gemfs);
-			return err;
-		}
-	}
 
 	i915->mm.gemfs = gemfs;