* [PATCH 01/23] mm/shmem: introduce shmem_file_setup_with_mnt
[not found] <20170821183503.12246-1-matthew.auld@intel.com>
@ 2017-08-21 18:34 ` Matthew Auld
2017-08-23 9:31 ` Joonas Lahtinen
2017-08-21 18:34 ` [PATCH 02/23] drm/i915: introduce simple gemfs Matthew Auld
1 sibling, 1 reply; 8+ messages in thread
From: Matthew Auld @ 2017-08-21 18:34 UTC (permalink / raw)
To: intel-gfx
Cc: Joonas Lahtinen, Chris Wilson, Dave Hansen, Kirill A . Shutemov,
Hugh Dickins, linux-mm
We are planning to use our own tmpfs mnt in i915 in place of the
shm_mnt, such that we can control the mount options, in particular
huge=, which we require to support huge-gtt-pages. So rather than roll
our own version of __shmem_file_setup, it would be preferred if we could
just give shmem our mnt, and let it do the rest.
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>
Cc: Dave Hansen <dave.hansen@intel.com>
Cc: Kirill A. Shutemov <kirill@shutemov.name>
Cc: Hugh Dickins <hughd@google.com>
Cc: linux-mm@kvack.org
Acked-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
---
include/linux/shmem_fs.h | 2 ++
mm/shmem.c | 30 ++++++++++++++++++++++--------
2 files changed, 24 insertions(+), 8 deletions(-)
diff --git a/include/linux/shmem_fs.h b/include/linux/shmem_fs.h
index a7d6bd2a918f..27de676f0b63 100644
--- a/include/linux/shmem_fs.h
+++ b/include/linux/shmem_fs.h
@@ -53,6 +53,8 @@ extern struct file *shmem_file_setup(const char *name,
loff_t size, unsigned long flags);
extern struct file *shmem_kernel_file_setup(const char *name, loff_t size,
unsigned long flags);
+extern struct file *shmem_file_setup_with_mnt(struct vfsmount *mnt,
+ const char *name, loff_t size, unsigned long flags);
extern int shmem_zero_setup(struct vm_area_struct *);
extern unsigned long shmem_get_unmapped_area(struct file *, unsigned long addr,
unsigned long len, unsigned long pgoff, unsigned long flags);
diff --git a/mm/shmem.c b/mm/shmem.c
index 6540e5982444..0975e65ea61c 100644
--- a/mm/shmem.c
+++ b/mm/shmem.c
@@ -4141,7 +4141,7 @@ static const struct dentry_operations anon_ops = {
.d_dname = simple_dname
};
-static struct file *__shmem_file_setup(const char *name, loff_t size,
+static struct file *__shmem_file_setup(struct vfsmount *mnt, const char *name, loff_t size,
unsigned long flags, unsigned int i_flags)
{
struct file *res;
@@ -4150,8 +4150,8 @@ static struct file *__shmem_file_setup(const char *name, loff_t size,
struct super_block *sb;
struct qstr this;
- if (IS_ERR(shm_mnt))
- return ERR_CAST(shm_mnt);
+ if (IS_ERR(mnt))
+ return ERR_CAST(mnt);
if (size < 0 || size > MAX_LFS_FILESIZE)
return ERR_PTR(-EINVAL);
@@ -4163,8 +4163,8 @@ static struct file *__shmem_file_setup(const char *name, loff_t size,
this.name = name;
this.len = strlen(name);
this.hash = 0; /* will go */
- sb = shm_mnt->mnt_sb;
- path.mnt = mntget(shm_mnt);
+ sb = mnt->mnt_sb;
+ path.mnt = mntget(mnt);
path.dentry = d_alloc_pseudo(sb, &this);
if (!path.dentry)
goto put_memory;
@@ -4209,7 +4209,7 @@ static struct file *__shmem_file_setup(const char *name, loff_t size,
*/
struct file *shmem_kernel_file_setup(const char *name, loff_t size, unsigned long flags)
{
- return __shmem_file_setup(name, size, flags, S_PRIVATE);
+ return __shmem_file_setup(shm_mnt, name, size, flags, S_PRIVATE);
}
/**
@@ -4220,11 +4220,25 @@ struct file *shmem_kernel_file_setup(const char *name, loff_t size, unsigned lon
*/
struct file *shmem_file_setup(const char *name, loff_t size, unsigned long flags)
{
- return __shmem_file_setup(name, size, flags, 0);
+ return __shmem_file_setup(shm_mnt, name, size, flags, 0);
}
EXPORT_SYMBOL_GPL(shmem_file_setup);
/**
+ * shmem_file_setup_with_mnt - get an unlinked file living in tmpfs
+ * @mnt: the tmpfs mount where the file will be created
+ * @name: name for dentry (to be seen in /proc/<pid>/maps
+ * @size: size to be set for the file
+ * @flags: VM_NORESERVE suppresses pre-accounting of the entire object size
+ */
+struct file *shmem_file_setup_with_mnt(struct vfsmount *mnt, const char *name,
+ loff_t size, unsigned long flags)
+{
+ return __shmem_file_setup(mnt, name, size, flags, 0);
+}
+EXPORT_SYMBOL_GPL(shmem_file_setup_with_mnt);
+
+/**
* shmem_zero_setup - setup a shared anonymous mapping
* @vma: the vma to be mmapped is prepared by do_mmap_pgoff
*/
@@ -4239,7 +4253,7 @@ int shmem_zero_setup(struct vm_area_struct *vma)
* accessible to the user through its mapping, use S_PRIVATE flag to
* bypass file security, in the same way as shmem_kernel_file_setup().
*/
- file = __shmem_file_setup("dev/zero", size, vma->vm_flags, S_PRIVATE);
+ file = shmem_kernel_file_setup("dev/zero", size, vma->vm_flags);
if (IS_ERR(file))
return PTR_ERR(file);
--
2.13.5
--
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>
^ permalink raw reply related [flat|nested] 8+ messages in thread
* [PATCH 02/23] drm/i915: introduce simple gemfs
[not found] <20170821183503.12246-1-matthew.auld@intel.com>
2017-08-21 18:34 ` [PATCH 01/23] mm/shmem: introduce shmem_file_setup_with_mnt Matthew Auld
@ 2017-08-21 18:34 ` Matthew Auld
2017-08-29 14:33 ` Joonas Lahtinen
1 sibling, 1 reply; 8+ messages in thread
From: Matthew Auld @ 2017-08-21 18:34 UTC (permalink / raw)
To: intel-gfx
Cc: Joonas Lahtinen, Chris Wilson, Dave Hansen, Kirill A . Shutemov,
Hugh Dickins, linux-mm
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
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>
Cc: Dave Hansen <dave.hansen@intel.com>
Cc: Kirill A. Shutemov <kirill@shutemov.name>
Cc: Hugh Dickins <hughd@google.com>
Cc: linux-mm@kvack.org
---
drivers/gpu/drm/i915/Makefile | 1 +
drivers/gpu/drm/i915/i915_drv.h | 3 ++
drivers/gpu/drm/i915/i915_gem.c | 34 +++++++++++++++-
drivers/gpu/drm/i915/i915_gemfs.c | 52 ++++++++++++++++++++++++
drivers/gpu/drm/i915/i915_gemfs.h | 34 ++++++++++++++++
drivers/gpu/drm/i915/selftests/mock_gem_device.c | 10 ++++-
6 files changed, 131 insertions(+), 3 deletions(-)
create mode 100644 drivers/gpu/drm/i915/i915_gemfs.c
create mode 100644 drivers/gpu/drm/i915/i915_gemfs.h
diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index 892f52b53060..24c3f672256b 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -47,6 +47,7 @@ i915-y += i915_cmd_parser.o \
i915_gem_tiling.o \
i915_gem_timeline.o \
i915_gem_userptr.o \
+ i915_gemfs.o \
i915_trace_points.o \
i915_vma.o \
intel_breadcrumbs.o \
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 60267e375e88..a3100f37bcae 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1468,6 +1468,9 @@ struct i915_gem_mm {
/** Usable portion of the GTT for GEM */
dma_addr_t stolen_base; /* limited to low memory (32-bit) */
+ /** tmpfs instance used for shmem backed objects */
+ struct vfsmount *gemfs;
+
/** PPGTT used for aliasing the PPGTT with the GTT */
struct i915_hw_ppgtt *aliasing_ppgtt;
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index b9e8e0d6e97b..3aece90b96c7 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -35,6 +35,7 @@
#include "intel_drv.h"
#include "intel_frontbuffer.h"
#include "intel_mocs.h"
+#include "i915_gemfs.h"
#include <linux/dma-fence-array.h>
#include <linux/kthread.h>
#include <linux/reservation.h>
@@ -4288,6 +4289,25 @@ static const struct drm_i915_gem_object_ops i915_gem_object_ops = {
.pwrite = i915_gem_object_pwrite_gtt,
};
+static int i915_gem_object_create_shmem(struct drm_device *dev,
+ struct drm_gem_object *obj,
+ size_t size)
+{
+ struct drm_i915_private *i915 = to_i915(dev);
+ struct file *filp;
+
+ drm_gem_private_object_init(dev, obj, size);
+
+ filp = shmem_file_setup_with_mnt(i915->mm.gemfs, "i915", size,
+ VM_NORESERVE);
+ if (IS_ERR(filp))
+ return PTR_ERR(filp);
+
+ obj->filp = filp;
+
+ return 0;
+}
+
struct drm_i915_gem_object *
i915_gem_object_create(struct drm_i915_private *dev_priv, u64 size)
{
@@ -4312,7 +4332,7 @@ i915_gem_object_create(struct drm_i915_private *dev_priv, u64 size)
if (obj == NULL)
return ERR_PTR(-ENOMEM);
- ret = drm_gem_object_init(&dev_priv->drm, &obj->base, size);
+ ret = i915_gem_object_create_shmem(&dev_priv->drm, &obj->base, size);
if (ret)
goto fail;
@@ -4887,7 +4907,13 @@ i915_gem_load_init_fences(struct drm_i915_private *dev_priv)
int
i915_gem_load_init(struct drm_i915_private *dev_priv)
{
- int err = -ENOMEM;
+ int err;
+
+ err = i915_gemfs_init(dev_priv);
+ if (err)
+ return err;
+
+ err = -ENOMEM;
dev_priv->objects = KMEM_CACHE(drm_i915_gem_object, SLAB_HWCACHE_ALIGN);
if (!dev_priv->objects)
@@ -4957,6 +4983,8 @@ i915_gem_load_init(struct drm_i915_private *dev_priv)
err_objects:
kmem_cache_destroy(dev_priv->objects);
err_out:
+ i915_gemfs_fini(dev_priv);
+
return err;
}
@@ -4980,6 +5008,8 @@ void i915_gem_load_cleanup(struct drm_i915_private *dev_priv)
/* And ensure that our DESTROY_BY_RCU slabs are truly destroyed */
rcu_barrier();
+
+ i915_gemfs_fini(dev_priv);
}
int i915_gem_freeze(struct drm_i915_private *dev_priv)
diff --git a/drivers/gpu/drm/i915/i915_gemfs.c b/drivers/gpu/drm/i915/i915_gemfs.c
new file mode 100644
index 000000000000..168d0bd98f60
--- /dev/null
+++ b/drivers/gpu/drm/i915/i915_gemfs.c
@@ -0,0 +1,52 @@
+/*
+ * Copyright A(C) 2017 Intel Corporation
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the "Software"),
+ * to deal in the Software without restriction, including without limitation
+ * the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ * and/or sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice (including the next
+ * paragraph) shall be included in all copies or substantial portions of the
+ * Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
+ * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS
+ * IN THE SOFTWARE.
+ *
+ */
+
+#include <linux/fs.h>
+#include <linux/mount.h>
+
+#include "i915_drv.h"
+#include "i915_gemfs.h"
+
+int i915_gemfs_init(struct drm_i915_private *i915)
+{
+ struct file_system_type *type;
+ struct vfsmount *gemfs;
+
+ type = get_fs_type("tmpfs");
+ if (!type)
+ return -ENODEV;
+
+ gemfs = kern_mount(type);
+ if (IS_ERR(gemfs))
+ return PTR_ERR(gemfs);
+
+ i915->mm.gemfs = gemfs;
+
+ return 0;
+}
+
+void i915_gemfs_fini(struct drm_i915_private *i915)
+{
+ kern_unmount(i915->mm.gemfs);
+}
diff --git a/drivers/gpu/drm/i915/i915_gemfs.h b/drivers/gpu/drm/i915/i915_gemfs.h
new file mode 100644
index 000000000000..cca8bdc5b93e
--- /dev/null
+++ b/drivers/gpu/drm/i915/i915_gemfs.h
@@ -0,0 +1,34 @@
+/*
+ * Copyright A(C) 2017 Intel Corporation
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the "Software"),
+ * to deal in the Software without restriction, including without limitation
+ * the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ * and/or sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice (including the next
+ * paragraph) shall be included in all copies or substantial portions of the
+ * Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
+ * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS
+ * IN THE SOFTWARE.
+ *
+ */
+
+#ifndef __I915_GEMFS_H__
+#define __I915_GEMFS_H__
+
+struct drm_i915_private;
+
+int i915_gemfs_init(struct drm_i915_private *i915);
+
+void i915_gemfs_fini(struct drm_i915_private *i915);
+
+#endif
diff --git a/drivers/gpu/drm/i915/selftests/mock_gem_device.c b/drivers/gpu/drm/i915/selftests/mock_gem_device.c
index 678723430d78..4d82c978a769 100644
--- a/drivers/gpu/drm/i915/selftests/mock_gem_device.c
+++ b/drivers/gpu/drm/i915/selftests/mock_gem_device.c
@@ -83,6 +83,8 @@ static void mock_device_release(struct drm_device *dev)
kmem_cache_destroy(i915->vmas);
kmem_cache_destroy(i915->objects);
+ i915_gemfs_fini(i915);
+
drm_dev_fini(&i915->drm);
put_device(&i915->drm.pdev->dev);
}
@@ -189,9 +191,13 @@ struct drm_i915_private *mock_gem_device(void)
i915->gt.awake = true;
+ err = i915_gemfs_init(i915);
+ if (err)
+ goto err_wq;
+
i915->objects = KMEM_CACHE(mock_object, SLAB_HWCACHE_ALIGN);
if (!i915->objects)
- goto err_wq;
+ goto err_gemfs;
i915->vmas = KMEM_CACHE(i915_vma, SLAB_HWCACHE_ALIGN);
if (!i915->vmas)
@@ -249,6 +255,8 @@ struct drm_i915_private *mock_gem_device(void)
kmem_cache_destroy(i915->vmas);
err_objects:
kmem_cache_destroy(i915->objects);
+err_gemfs:
+ i915_gemfs_fini(i915);
err_wq:
destroy_workqueue(i915->wq);
put_device:
--
2.13.5
--
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>
^ permalink raw reply related [flat|nested] 8+ messages in thread
* Re: [PATCH 01/23] mm/shmem: introduce shmem_file_setup_with_mnt
2017-08-21 18:34 ` [PATCH 01/23] mm/shmem: introduce shmem_file_setup_with_mnt Matthew Auld
@ 2017-08-23 9:31 ` Joonas Lahtinen
2017-08-23 22:34 ` Andrew Morton
0 siblings, 1 reply; 8+ messages in thread
From: Joonas Lahtinen @ 2017-08-23 9:31 UTC (permalink / raw)
To: Andrew Morton
Cc: Matthew Auld, intel-gfx, Chris Wilson, Dave Hansen,
Kirill A . Shutemov, Hugh Dickins, linux-mm
Hi Andrew,
This patch has been floating around for a while now Acked and without
further comments. It is blocking us from merging huge page support to
drm/i915.
Would you mind merging it, or prodding the right people to get it in?
Regards, Joonas
On Mon, 2017-08-21 at 19:34 +0100, Matthew Auld wrote:
> We are planning to use our own tmpfs mnt in i915 in place of the
> shm_mnt, such that we can control the mount options, in particular
> huge=, which we require to support huge-gtt-pages. So rather than roll
> our own version of __shmem_file_setup, it would be preferred if we could
> just give shmem our mnt, and let it do the rest.
>
> 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>
> Cc: Dave Hansen <dave.hansen@intel.com>
> Cc: Kirill A. Shutemov <kirill@shutemov.name>
> Cc: Hugh Dickins <hughd@google.com>
> Cc: linux-mm@kvack.org
> Acked-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
> Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
> ---
> include/linux/shmem_fs.h | 2 ++
> mm/shmem.c | 30 ++++++++++++++++++++++--------
> 2 files changed, 24 insertions(+), 8 deletions(-)
>
> diff --git a/include/linux/shmem_fs.h b/include/linux/shmem_fs.h
> index a7d6bd2a918f..27de676f0b63 100644
> --- a/include/linux/shmem_fs.h
> +++ b/include/linux/shmem_fs.h
> @@ -53,6 +53,8 @@ extern struct file *shmem_file_setup(const char *name,
> loff_t size, unsigned long flags);
> extern struct file *shmem_kernel_file_setup(const char *name, loff_t size,
> unsigned long flags);
> +extern struct file *shmem_file_setup_with_mnt(struct vfsmount *mnt,
> + const char *name, loff_t size, unsigned long flags);
> extern int shmem_zero_setup(struct vm_area_struct *);
> extern unsigned long shmem_get_unmapped_area(struct file *, unsigned long addr,
> unsigned long len, unsigned long pgoff, unsigned long flags);
> diff --git a/mm/shmem.c b/mm/shmem.c
> index 6540e5982444..0975e65ea61c 100644
> --- a/mm/shmem.c
> +++ b/mm/shmem.c
> @@ -4141,7 +4141,7 @@ static const struct dentry_operations anon_ops = {
> .d_dname = simple_dname
> };
>
> -static struct file *__shmem_file_setup(const char *name, loff_t size,
> +static struct file *__shmem_file_setup(struct vfsmount *mnt, const char *name, loff_t size,
> unsigned long flags, unsigned int i_flags)
> {
> struct file *res;
> @@ -4150,8 +4150,8 @@ static struct file *__shmem_file_setup(const char *name, loff_t size,
> struct super_block *sb;
> struct qstr this;
>
> - if (IS_ERR(shm_mnt))
> - return ERR_CAST(shm_mnt);
> + if (IS_ERR(mnt))
> + return ERR_CAST(mnt);
>
> if (size < 0 || size > MAX_LFS_FILESIZE)
> return ERR_PTR(-EINVAL);
> @@ -4163,8 +4163,8 @@ static struct file *__shmem_file_setup(const char *name, loff_t size,
> this.name = name;
> this.len = strlen(name);
> this.hash = 0; /* will go */
> - sb = shm_mnt->mnt_sb;
> - path.mnt = mntget(shm_mnt);
> + sb = mnt->mnt_sb;
> + path.mnt = mntget(mnt);
> path.dentry = d_alloc_pseudo(sb, &this);
> if (!path.dentry)
> goto put_memory;
> @@ -4209,7 +4209,7 @@ static struct file *__shmem_file_setup(const char *name, loff_t size,
> */
> struct file *shmem_kernel_file_setup(const char *name, loff_t size, unsigned long flags)
> {
> - return __shmem_file_setup(name, size, flags, S_PRIVATE);
> + return __shmem_file_setup(shm_mnt, name, size, flags, S_PRIVATE);
> }
>
> /**
> @@ -4220,11 +4220,25 @@ struct file *shmem_kernel_file_setup(const char *name, loff_t size, unsigned lon
> */
> struct file *shmem_file_setup(const char *name, loff_t size, unsigned long flags)
> {
> - return __shmem_file_setup(name, size, flags, 0);
> + return __shmem_file_setup(shm_mnt, name, size, flags, 0);
> }
> EXPORT_SYMBOL_GPL(shmem_file_setup);
>
> /**
> + * shmem_file_setup_with_mnt - get an unlinked file living in tmpfs
> + * @mnt: the tmpfs mount where the file will be created
> + * @name: name for dentry (to be seen in /proc/<pid>/maps
> + * @size: size to be set for the file
> + * @flags: VM_NORESERVE suppresses pre-accounting of the entire object size
> + */
> +struct file *shmem_file_setup_with_mnt(struct vfsmount *mnt, const char *name,
> + loff_t size, unsigned long flags)
> +{
> + return __shmem_file_setup(mnt, name, size, flags, 0);
> +}
> +EXPORT_SYMBOL_GPL(shmem_file_setup_with_mnt);
> +
> +/**
> * shmem_zero_setup - setup a shared anonymous mapping
> * @vma: the vma to be mmapped is prepared by do_mmap_pgoff
> */
> @@ -4239,7 +4253,7 @@ int shmem_zero_setup(struct vm_area_struct *vma)
> * accessible to the user through its mapping, use S_PRIVATE flag to
> * bypass file security, in the same way as shmem_kernel_file_setup().
> */
> - file = __shmem_file_setup("dev/zero", size, vma->vm_flags, S_PRIVATE);
> + file = shmem_kernel_file_setup("dev/zero", size, vma->vm_flags);
> if (IS_ERR(file))
> return PTR_ERR(file);
>
--
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>
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [PATCH 01/23] mm/shmem: introduce shmem_file_setup_with_mnt
2017-08-23 9:31 ` Joonas Lahtinen
@ 2017-08-23 22:34 ` Andrew Morton
2017-08-24 12:04 ` [Intel-gfx] " Matthew Auld
0 siblings, 1 reply; 8+ messages in thread
From: Andrew Morton @ 2017-08-23 22:34 UTC (permalink / raw)
To: Joonas Lahtinen
Cc: Matthew Auld, intel-gfx, Chris Wilson, Dave Hansen,
Kirill A . Shutemov, Hugh Dickins, linux-mm
On Wed, 23 Aug 2017 12:31:28 +0300 Joonas Lahtinen <joonas.lahtinen@linux.intel.com> wrote:
> This patch has been floating around for a while now Acked and without
> further comments. It is blocking us from merging huge page support to
> drm/i915.
>
> Would you mind merging it, or prodding the right people to get it in?
>
> Regards, Joonas
>
> On Mon, 2017-08-21 at 19:34 +0100, Matthew Auld wrote:
> > We are planning to use our own tmpfs mnt in i915 in place of the
> > shm_mnt, such that we can control the mount options, in particular
> > huge=, which we require to support huge-gtt-pages. So rather than roll
> > our own version of __shmem_file_setup, it would be preferred if we could
> > just give shmem our mnt, and let it do the rest.
hm, it's a bit odd. I'm having trouble locating the code which handles
huge=within_size (and any other options?). What other approaches were
considered? Was it not feasible to add i915-specific mount options to
mm/shmem.c (for example?).
--
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>
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [Intel-gfx] [PATCH 01/23] mm/shmem: introduce shmem_file_setup_with_mnt
2017-08-23 22:34 ` Andrew Morton
@ 2017-08-24 12:04 ` Matthew Auld
2017-08-25 20:49 ` Andrew Morton
0 siblings, 1 reply; 8+ messages in thread
From: Matthew Auld @ 2017-08-24 12:04 UTC (permalink / raw)
To: Andrew Morton
Cc: Joonas Lahtinen, linux-mm, Intel Graphics Development,
Hugh Dickins, Dave Hansen, Matthew Auld, Kirill A . Shutemov
On 23 August 2017 at 23:34, Andrew Morton <akpm@linux-foundation.org> wrote:
> On Wed, 23 Aug 2017 12:31:28 +0300 Joonas Lahtinen <joonas.lahtinen@linux.intel.com> wrote:
>
>> This patch has been floating around for a while now Acked and without
>> further comments. It is blocking us from merging huge page support to
>> drm/i915.
>>
>> Would you mind merging it, or prodding the right people to get it in?
>>
>> Regards, Joonas
>>
>> On Mon, 2017-08-21 at 19:34 +0100, Matthew Auld wrote:
>> > We are planning to use our own tmpfs mnt in i915 in place of the
>> > shm_mnt, such that we can control the mount options, in particular
>> > huge=, which we require to support huge-gtt-pages. So rather than roll
>> > our own version of __shmem_file_setup, it would be preferred if we could
>> > just give shmem our mnt, and let it do the rest.
>
> hm, it's a bit odd. I'm having trouble locating the code which handles
> huge=within_size (and any other options?).
See here https://patchwork.freedesktop.org/patch/172771/, currently we
only care about huge=within_size.
> What other approaches were considered?
We also tried https://patchwork.freedesktop.org/patch/156528/, where
it was suggested that we mount our own tmpfs instance.
Following from that we now have our own tmps mnt mounted with
huge=within_size. With this patch we avoid having to roll our own
__shmem_file_setup like in
https://patchwork.freedesktop.org/patch/163024/.
> Was it not feasible to add i915-specific mount options to
> mm/shmem.c (for example?).
Hmm, I think within_size should suffice for our needs.
>
> _______________________________________________
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
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>
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [Intel-gfx] [PATCH 01/23] mm/shmem: introduce shmem_file_setup_with_mnt
2017-08-24 12:04 ` [Intel-gfx] " Matthew Auld
@ 2017-08-25 20:49 ` Andrew Morton
2017-08-29 14:09 ` Joonas Lahtinen
0 siblings, 1 reply; 8+ messages in thread
From: Andrew Morton @ 2017-08-25 20:49 UTC (permalink / raw)
To: Matthew Auld
Cc: Joonas Lahtinen, linux-mm, Intel Graphics Development,
Hugh Dickins, Dave Hansen, Matthew Auld, Kirill A . Shutemov
On Thu, 24 Aug 2017 13:04:09 +0100 Matthew Auld <matthew.william.auld@gmail.com> wrote:
> On 23 August 2017 at 23:34, Andrew Morton <akpm@linux-foundation.org> wrote:
> > On Wed, 23 Aug 2017 12:31:28 +0300 Joonas Lahtinen <joonas.lahtinen@linux.intel.com> wrote:
> >
> >> This patch has been floating around for a while now Acked and without
> >> further comments. It is blocking us from merging huge page support to
> >> drm/i915.
> >>
> >> Would you mind merging it, or prodding the right people to get it in?
> >>
> >> Regards, Joonas
> >>
> >> On Mon, 2017-08-21 at 19:34 +0100, Matthew Auld wrote:
> >> > We are planning to use our own tmpfs mnt in i915 in place of the
> >> > shm_mnt, such that we can control the mount options, in particular
> >> > huge=, which we require to support huge-gtt-pages. So rather than roll
> >> > our own version of __shmem_file_setup, it would be preferred if we could
> >> > just give shmem our mnt, and let it do the rest.
> >
> > hm, it's a bit odd. I'm having trouble locating the code which handles
> > huge=within_size (and any other options?).
>
> See here https://patchwork.freedesktop.org/patch/172771/, currently we
> only care about huge=within_size.
>
> > What other approaches were considered?
>
> We also tried https://patchwork.freedesktop.org/patch/156528/, where
> it was suggested that we mount our own tmpfs instance.
>
> Following from that we now have our own tmps mnt mounted with
> huge=within_size. With this patch we avoid having to roll our own
> __shmem_file_setup like in
> https://patchwork.freedesktop.org/patch/163024/.
>
> > Was it not feasible to add i915-specific mount options to
> > mm/shmem.c (for example?).
>
> Hmm, I think within_size should suffice for our needs.
hm, ok, well, unless someone can think of something cleaner, please add
my ack and include it in the appropriate drm tree.
--
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>
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [Intel-gfx] [PATCH 01/23] mm/shmem: introduce shmem_file_setup_with_mnt
2017-08-25 20:49 ` Andrew Morton
@ 2017-08-29 14:09 ` Joonas Lahtinen
0 siblings, 0 replies; 8+ messages in thread
From: Joonas Lahtinen @ 2017-08-29 14:09 UTC (permalink / raw)
To: Andrew Morton, Matthew Auld, Chris Wilson
Cc: linux-mm, Intel Graphics Development, Hugh Dickins, Dave Hansen,
Matthew Auld, Kirill A . Shutemov
On Fri, 2017-08-25 at 13:49 -0700, Andrew Morton wrote:
> On Thu, 24 Aug 2017 13:04:09 +0100 Matthew Auld <matthew.william.auld@gmail.com> wrote:
>
> > On 23 August 2017 at 23:34, Andrew Morton <akpm@linux-foundation.org> wrote:
> > > On Wed, 23 Aug 2017 12:31:28 +0300 Joonas Lahtinen <joonas.lahtinen@linux.intel.com> wrote:
> > >
> > > > This patch has been floating around for a while now Acked and without
> > > > further comments. It is blocking us from merging huge page support to
> > > > drm/i915.
> > > >
> > > > Would you mind merging it, or prodding the right people to get it in?
> > > >
> > > > Regards, Joonas
> > > >
> > > > On Mon, 2017-08-21 at 19:34 +0100, Matthew Auld wrote:
> > > > > We are planning to use our own tmpfs mnt in i915 in place of the
> > > > > shm_mnt, such that we can control the mount options, in particular
> > > > > huge=, which we require to support huge-gtt-pages. So rather than roll
> > > > > our own version of __shmem_file_setup, it would be preferred if we could
> > > > > just give shmem our mnt, and let it do the rest.
> > >
> > > hm, it's a bit odd. I'm having trouble locating the code which handles
> > > huge=within_size (and any other options?).
> >
> > See here https://patchwork.freedesktop.org/patch/172771/, currently we
> > only care about huge=within_size.
> >
> > > What other approaches were considered?
> >
> > We also tried https://patchwork.freedesktop.org/patch/156528/, where
> > it was suggested that we mount our own tmpfs instance.
> >
> > Following from that we now have our own tmps mnt mounted with
> > huge=within_size. With this patch we avoid having to roll our own
> > __shmem_file_setup like in
> > https://patchwork.freedesktop.org/patch/163024/.
> >
> > > Was it not feasible to add i915-specific mount options to
> > > mm/shmem.c (for example?).
> >
> > Hmm, I think within_size should suffice for our needs.
>
> hm, ok, well, unless someone can think of something cleaner, please add
> my ack and include it in the appropriate drm tree.
Thanks, I will do that. It'll first get incorporated into drm-tip (
https://cgit.freedesktop.org/drm-tip) once the kselftests are finalized
(now that we know we're not facing third rewrite for core MM
dependency). And eventually into drm-next through a pull request to
Dave Airlie.
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>
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [PATCH 02/23] drm/i915: introduce simple gemfs
2017-08-21 18:34 ` [PATCH 02/23] drm/i915: introduce simple gemfs Matthew Auld
@ 2017-08-29 14:33 ` Joonas Lahtinen
0 siblings, 0 replies; 8+ messages in thread
From: Joonas Lahtinen @ 2017-08-29 14:33 UTC (permalink / raw)
To: Matthew Auld, intel-gfx
Cc: Chris Wilson, Dave Hansen, Kirill A . Shutemov, Hugh Dickins, linux-mm
On Mon, 2017-08-21 at 19:34 +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
>
> 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>
> Cc: Dave Hansen <dave.hansen@intel.com>
> Cc: Kirill A. Shutemov <kirill@shutemov.name>
> Cc: Hugh Dickins <hughd@google.com>
> Cc: linux-mm@kvack.org
<SNIP>
> @@ -4288,6 +4289,25 @@ static const struct drm_i915_gem_object_ops i915_gem_object_ops = {
> .pwrite = i915_gem_object_pwrite_gtt,
> };
>
> +static int i915_gem_object_create_shmem(struct drm_device *dev,
> + struct drm_gem_object *obj,
> + size_t size)
> +{
> + struct drm_i915_private *i915 = to_i915(dev);
> + struct file *filp;
> +
> + drm_gem_private_object_init(dev, obj, size);
> +
> + filp = shmem_file_setup_with_mnt(i915->mm.gemfs, "i915", size,
> + VM_NORESERVE);
Can you double-check that /proc/meminfo is unaffected by this change?
If we stop appearing under "Shemem:" we maybe need to maybe highlight
this somewhere (at least in commit message).
<SNIP>
> +int i915_gemfs_init(struct drm_i915_private *i915)
> +{
> + struct file_system_type *type;
> + struct vfsmount *gemfs;
> +
> + type = get_fs_type("tmpfs");
> + if (!type)
> + return -ENODEV;
> +
> + gemfs = kern_mount(type);
> + if (IS_ERR(gemfs))
> + return PTR_ERR(gemfs);
By occasionally checking that "i915->mm.gemfs" might be NULL, could we
continue without our own gemfs mount and just lose the additional
features? Or is it not worth the hassle?
Anyway, this is:
Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
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>
^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2017-08-29 14:33 UTC | newest]
Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
[not found] <20170821183503.12246-1-matthew.auld@intel.com>
2017-08-21 18:34 ` [PATCH 01/23] mm/shmem: introduce shmem_file_setup_with_mnt Matthew Auld
2017-08-23 9:31 ` Joonas Lahtinen
2017-08-23 22:34 ` Andrew Morton
2017-08-24 12:04 ` [Intel-gfx] " Matthew Auld
2017-08-25 20:49 ` Andrew Morton
2017-08-29 14:09 ` Joonas Lahtinen
2017-08-21 18:34 ` [PATCH 02/23] drm/i915: introduce simple gemfs Matthew Auld
2017-08-29 14:33 ` Joonas Lahtinen
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).