linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Dave Airlie <airlied@gmail.com>
To: LKML <linux-kernel@vger.kernel.org>,
	Linux Memory Management List <linux-mm@kvack.org>,
	dri-devel <dri-devel@lists.freedesktop.org>
Subject: making a COW mapping on the fly from existing vma
Date: Sat, 16 Apr 2016 06:18:38 +1000	[thread overview]
Message-ID: <CAPM=9twrh8wVin=A1Zva3DD0iBmM-G8GjdSnzOD-b0=h4SVxyw@mail.gmail.com> (raw)

This was just a random thought process I was having last night, and
wondered if it was possible.

We have a scenario with OpenGL where certain APIs hand large amounts
of data from the user to the API and when you return from the API call
the user can then free/overwrite/do whatever they want with the data
they gave you, which pretty much means you have to straight away
process the data.

Now there have been attempts at threading the GL API, but one thing
they usually hit is they have to do a lot of unthreaded processing for
these scenarios, so I was wondering could we do some COW magic with
the data.

More than likely the data will be anonymous mappings though maybe some
filebacked, and my idea would be you'd in the main thread create a new
readonly VMA from the old pages and set the original mapping to do COW
on all of its pages. Then the thread would pick up the readonly VMA
mapping and do whatever background processing it wants while the main
thread continues happily on its way.

I'm not sure if anyone who's done glthread has thought around this, or
if the kernel APIs are in place to do something like this so I just
thought I'd throw it out there.

Dave.

--
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:[~2016-04-15 20:18 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-04-15 20:18 Dave Airlie [this message]
2016-04-18 13:58 ` Jerome Glisse

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='CAPM=9twrh8wVin=A1Zva3DD0iBmM-G8GjdSnzOD-b0=h4SVxyw@mail.gmail.com' \
    --to=airlied@gmail.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox