From: Hugh Dickins <hughd@google.com>
To: Matthew Auld <matthew.william.auld@gmail.com>
Cc: Intel Graphics Development <intel-gfx@lists.freedesktop.org>,
Hugh Dickins <hughd@google.com>,
Sourab Gupta <sourab.gupta@intel.com>,
linux-mm@kvack.org, akash.goel@intel.com
Subject: Re: [PATCH 2/2] drm/i915: Make GPU pages movable
Date: Tue, 22 Nov 2016 21:26:11 -0800 (PST) [thread overview]
Message-ID: <alpine.LSU.2.11.1611222046510.1902@eggly.anvils> (raw)
In-Reply-To: <CAM0jSHPsD3+sAgK9bqDW3cm-C+PeAb-ojJq2JnEzC--HtyfMGg@mail.gmail.com>
On Tue, 22 Nov 2016, Matthew Auld wrote:
> On 9 November 2016 at 18:36, Hugh Dickins <hughd@google.com> wrote:
> > On Wed, 9 Nov 2016, Daniel Vetter wrote:
> >>
> >> Hi all -mm folks!
> >>
> >> Any feedback on these two? It's kinda an intermediate step towards a
> >> full-blown gemfs, and I think useful for that. Or do we need to go
> >> directly to our own backing storage thing? Aside from ack/nack from -mm I
> >> think this is ready for merging.
> >
> > I'm currently considering them at last: will report back later.
> >
> > Full-blown gemfs does not come in here, of course; but let me
> > fire a warning shot since you mention it: if it's going to use swap,
> > then we shall probably have to nak it in favour of continuing to use
> > infrastructure from mm/shmem.c. I very much understand why you would
> > love to avoid that dependence, but I doubt it can be safely bypassed.
>
> Could you please elaborate on what specifically you don't like about
> gemfs implementing swap, just to make sure I'm following?
If we're talking about swap as implemented in mm/swapfile.c, and
managed for tmpfs mainly through shmem_getpage_gfp(): that's slippery
stuff, private to mm, and I would not want such trickiness duplicated
somewhere down in drivers/gpu/drm, where mm developers and drm developers
will keep on forgetting to keep it working correctly.
But you write of gemfs "implementing" swap (and I see Daniel wrote of
"our own backing storage"): perhaps you intend a disk or slow-mem file
of your own, dedicated to paging gemfs objects according to your own
rules, poked from memory reclaim via a shrinker. I certainly don't
have the same quick objection to that: it may be a good way forward,
though I'm not at all sure (and would prefer a name distinct from
swap, so we wouldn't get confused - maybe gemswap).
Hugh
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
WARNING: multiple messages have this Message-ID (diff)
From: Hugh Dickins <hughd@google.com>
To: Matthew Auld <matthew.william.auld@gmail.com>
Cc: Hugh Dickins <hughd@google.com>, Daniel Vetter <daniel@ffwll.ch>,
Intel Graphics Development <intel-gfx@lists.freedesktop.org>,
Sourab Gupta <sourab.gupta@intel.com>,
linux-mm@kvack.org, akash.goel@intel.com
Subject: Re: [Intel-gfx] [PATCH 2/2] drm/i915: Make GPU pages movable
Date: Tue, 22 Nov 2016 21:26:11 -0800 (PST) [thread overview]
Message-ID: <alpine.LSU.2.11.1611222046510.1902@eggly.anvils> (raw)
In-Reply-To: <CAM0jSHPsD3+sAgK9bqDW3cm-C+PeAb-ojJq2JnEzC--HtyfMGg@mail.gmail.com>
On Tue, 22 Nov 2016, Matthew Auld wrote:
> On 9 November 2016 at 18:36, Hugh Dickins <hughd@google.com> wrote:
> > On Wed, 9 Nov 2016, Daniel Vetter wrote:
> >>
> >> Hi all -mm folks!
> >>
> >> Any feedback on these two? It's kinda an intermediate step towards a
> >> full-blown gemfs, and I think useful for that. Or do we need to go
> >> directly to our own backing storage thing? Aside from ack/nack from -mm I
> >> think this is ready for merging.
> >
> > I'm currently considering them at last: will report back later.
> >
> > Full-blown gemfs does not come in here, of course; but let me
> > fire a warning shot since you mention it: if it's going to use swap,
> > then we shall probably have to nak it in favour of continuing to use
> > infrastructure from mm/shmem.c. I very much understand why you would
> > love to avoid that dependence, but I doubt it can be safely bypassed.
>
> Could you please elaborate on what specifically you don't like about
> gemfs implementing swap, just to make sure I'm following?
If we're talking about swap as implemented in mm/swapfile.c, and
managed for tmpfs mainly through shmem_getpage_gfp(): that's slippery
stuff, private to mm, and I would not want such trickiness duplicated
somewhere down in drivers/gpu/drm, where mm developers and drm developers
will keep on forgetting to keep it working correctly.
But you write of gemfs "implementing" swap (and I see Daniel wrote of
"our own backing storage"): perhaps you intend a disk or slow-mem file
of your own, dedicated to paging gemfs objects according to your own
rules, poked from memory reclaim via a shrinker. I certainly don't
have the same quick objection to that: it may be a good way forward,
though I'm not at all sure (and would prefer a name distinct from
swap, so we wouldn't get confused - maybe gemswap).
Hugh
--
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>
next prev parent reply other threads:[~2016-11-23 5:26 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-11-04 15:02 [PATCH 1/2] shmem: Support for registration of driver/file owner specific ops akash.goel
2016-11-04 15:02 ` [PATCH 2/2] drm/i915: Make GPU pages movable akash.goel
2016-11-09 11:28 ` Daniel Vetter
2016-11-09 18:36 ` Hugh Dickins
2016-11-22 16:02 ` [Intel-gfx] " Matthew Auld
2016-11-23 5:26 ` Hugh Dickins [this message]
2016-11-23 5:26 ` Hugh Dickins
2016-11-23 8:36 ` Daniel Vetter
2016-11-23 8:36 ` [Intel-gfx] " Daniel Vetter
2016-11-23 19:00 ` Hugh Dickins
2016-11-23 19:00 ` [Intel-gfx] " Hugh Dickins
2016-11-10 6:39 ` Hugh Dickins
2016-11-10 6:39 ` Hugh Dickins
2016-11-10 7:30 ` Goel, Akash
2016-11-14 7:57 ` akash goel
2016-11-16 1:25 ` Hugh Dickins
2016-11-16 1:25 ` Hugh Dickins
2016-11-16 5:13 ` akash goel
2016-11-16 5:13 ` akash goel
2016-11-04 17:15 ` ✓ Fi.CI.BAT: success for series starting with [1/2] shmem: Support for registration of driver/file owner specific ops Patchwork
2016-11-10 5:36 ` [PATCH 1/2] " Hugh Dickins
2016-11-10 16:22 ` Goel, Akash
2016-11-11 13:50 ` Chris Wilson
2016-11-11 13:50 ` Chris Wilson
-- strict thread matches above, loose matches on Subject: below --
2016-10-20 15:15 [PATCH 1/2] shmem: Support for registration of Driver/file " Joonas Lahtinen
2016-11-04 12:48 ` [PATCH 1/2] shmem: Support for registration of driver/file " akash.goel
2016-11-04 12:48 ` [PATCH 2/2] drm/i915: Make GPU pages movable akash.goel
2016-11-04 13:37 ` Chris Wilson
2016-11-04 13:37 ` Chris Wilson
2016-11-04 13:53 ` Goel, Akash
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=alpine.LSU.2.11.1611222046510.1902@eggly.anvils \
--to=hughd@google.com \
--cc=akash.goel@intel.com \
--cc=intel-gfx@lists.freedesktop.org \
--cc=linux-mm@kvack.org \
--cc=matthew.william.auld@gmail.com \
--cc=sourab.gupta@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.