From: Thomas Hellstrom <thellstrom@vmware.com>
To: linux-mm@kvack.org, linux-kernel@vger.kernel.org
Cc: linux-graphics-maintainer@vmware.com
Subject: [PATCH RFC 0/3] Add dirty-tracking infrastructure for non-page-backed address spaces
Date: Tue, 19 Nov 2013 12:06:13 -0800 [thread overview]
Message-ID: <1384891576-7851-1-git-send-email-thellstrom@vmware.com> (raw)
Hi!
Before going any further with this I'd like to check whether this is an
acceptable way to go.
Background:
GPU buffer objects in general and vmware svga GPU buffers in
particular are mapped by user-space using MIXEDMAP or PFNMAP. Sometimes the
address space is backed by a set of pages, sometimes it's backed by PCI memory.
In the latter case in particular, there is no way to track dirty regions
using page_mkwrite() and page_mkclean(), other than allocating a bounce
buffer and perform dirty tracking on it, and then copy data to the real GPU
buffer. This comes with a big memory- and performance overhead.
So I'd like to add the following infrastructure with a callback pfn_mkwrite()
and a function mkclean_mapping_range(). Typically we will be cleaning a range
of ptes rather than random ptes in a vma.
This comes with the extra benefit of being usable when the backing memory of
the GPU buffer is not coherent with the GPU itself, and where we either need
to flush caches or move data to synchronize.
So this is a RFC for
1) The API. Is it acceptable? Any other suggestions if not?
2) Modifying apply_to_page_range(). Better to make a standalone
non-populating version?
3) tlb- mmu- and cache-flushing calls. I've looked at unmap_mapping_range()
and page_mkclean_one() to try to get it right, but still unsure.
Thanks,
Thomas HellstrA?m
--
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 reply other threads:[~2013-11-19 20:06 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-11-19 20:06 Thomas Hellstrom [this message]
2013-11-19 20:06 ` [PATCH RFC 1/3] mm: Add pfn_mkwrite() Thomas Hellstrom
2013-11-19 20:06 ` [PATCH RFC 2/3] mm: Add a non-populating version of apply_to_page_range() Thomas Hellstrom
2013-11-19 20:06 ` [PATCH RFC 3/3] mm: Add mkclean_mapping_range() Thomas Hellstrom
2013-11-19 22:51 ` [PATCH RFC 0/3] Add dirty-tracking infrastructure for non-page-backed address spaces Andy Lutomirski
2013-11-20 8:12 ` Thomas Hellstrom
2013-11-20 16:50 ` Andy Lutomirski
2013-11-20 20:16 ` Thomas Hellstrom
2013-11-20 20:29 ` Andy Lutomirski
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=1384891576-7851-1-git-send-email-thellstrom@vmware.com \
--to=thellstrom@vmware.com \
--cc=linux-graphics-maintainer@vmware.com \
--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;
as well as URLs for NNTP newsgroup(s).