All of lore.kernel.org
 help / color / mirror / Atom feed
From: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
To: Matthew Auld <matthew.auld@intel.com>, intel-gfx@lists.freedesktop.org
Cc: Chris Wilson <chris@chris-wilson.co.uk>,
	Dave Hansen <dave.hansen@intel.com>,
	"Kirill A . Shutemov" <kirill@shutemov.name>,
	Hugh Dickins <hughd@google.com>,
	linux-mm@kvack.org
Subject: Re: [PATCH 02/23] drm/i915: introduce simple gemfs
Date: Tue, 29 Aug 2017 17:33:05 +0300	[thread overview]
Message-ID: <1504017185.5001.71.camel@linux.intel.com> (raw)
In-Reply-To: <20170821183503.12246-3-matthew.auld@intel.com>

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>

  reply	other threads:[~2017-08-29 14:33 UTC|newest]

Thread overview: 45+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-08-21 18:34 [PATCH 00/23] huge gtt pages Matthew Auld
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-23 22:34       ` Andrew Morton
2017-08-24 12:04       ` [Intel-gfx] " Matthew Auld
2017-08-24 12:04         ` Matthew Auld
2017-08-25 20:49         ` [Intel-gfx] " Andrew Morton
2017-08-25 20:49           ` Andrew Morton
2017-08-29 14:09           ` [Intel-gfx] " Joonas Lahtinen
2017-08-29 14:09             ` Joonas Lahtinen
2017-08-21 18:34 ` [PATCH 02/23] drm/i915: introduce simple gemfs Matthew Auld
2017-08-21 18:34   ` Matthew Auld
2017-08-29 14:33   ` Joonas Lahtinen [this message]
2017-08-21 18:34 ` [PATCH 03/23] drm/i915/gemfs: enable THP Matthew Auld
2017-08-29 14:49   ` Joonas Lahtinen
2017-09-04 12:09     ` Matthew Auld
2017-08-21 18:34 ` [PATCH 04/23] drm/i915: introduce page_size_mask to dev_info Matthew Auld
2017-08-21 18:34 ` [PATCH 05/23] drm/i915: push set_pages down to the callers Matthew Auld
2017-08-29 14:44   ` Joonas Lahtinen
2017-08-21 18:34 ` [PATCH 06/23] drm/i915: introduce page_size members Matthew Auld
2017-09-05  9:25   ` Joonas Lahtinen
2017-08-21 18:34 ` [PATCH 07/23] drm/i915: introduce vm set_pages/clear_pages Matthew Auld
2017-08-21 18:34 ` [PATCH 08/23] drm/i915: align the vma start to the largest gtt page size Matthew Auld
2017-08-21 18:34 ` [PATCH 09/23] drm/i915: align 64K objects to 2M Matthew Auld
2017-08-21 18:34 ` [PATCH 10/23] drm/i915: enable IPS bit for 64K pages Matthew Auld
2017-08-21 18:34 ` [PATCH 11/23] drm/i915: disable GTT cache for 2M/1G pages Matthew Auld
2017-08-21 18:34 ` [PATCH 12/23] drm/i915: support 1G pages for the 48b PPGTT Matthew Auld
2017-08-21 18:34 ` [PATCH 13/23] drm/i915: support 2M " Matthew Auld
2017-08-21 18:34 ` [PATCH 14/23] drm/i915: add support for 64K scratch page Matthew Auld
2017-08-21 18:34 ` [PATCH 15/23] drm/i915: support 64K pages for the 48b PPGTT Matthew Auld
2017-08-21 18:34 ` [PATCH 16/23] drm/i915: accurate page size tracking for the ppgtt Matthew Auld
2017-08-21 18:34 ` [PATCH 17/23] drm/i915/debugfs: include some gtt page size metrics Matthew Auld
2017-08-21 18:34 ` [PATCH 18/23] drm/i915/selftests: huge page tests Matthew Auld
2017-08-24 17:56   ` kbuild test robot
2017-08-28 14:36     ` Chris Wilson
2017-08-21 18:34 ` [PATCH 19/23] drm/i915/selftests: mix huge pages Matthew Auld
2017-08-21 18:35 ` [PATCH 20/23] drm/i915: disable platform support for vGPU huge gtt pages Matthew Auld
2017-08-21 18:35 ` [PATCH 21/23] drm/i915: enable platform support for 64K pages Matthew Auld
2017-08-21 18:35 ` [PATCH 22/23] drm/i915: enable platform support for 2M pages Matthew Auld
2017-08-21 18:35 ` [PATCH 23/23] drm/i915: enable platform support for 1G pages Matthew Auld
2017-08-21 18:54 ` ✓ Fi.CI.BAT: success for huge gtt pages (rev7) Patchwork
2017-08-22 14:21 ` [PATCH 00/23] huge gtt pages Chris Wilson
2017-08-22 14:23   ` Chris Wilson
2017-08-22 15:23     ` Matthew Auld

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1504017185.5001.71.camel@linux.intel.com \
    --to=joonas.lahtinen@linux.intel.com \
    --cc=chris@chris-wilson.co.uk \
    --cc=dave.hansen@intel.com \
    --cc=hughd@google.com \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=kirill@shutemov.name \
    --cc=linux-mm@kvack.org \
    --cc=matthew.auld@intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.