On 11/19/2013 12:06 PM, Thomas Hellstrom wrote:Hi!Most (all?) architectures have real dirty tracking -- you can mark a pte
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.
as "clean" and the hardware (or arch code) will mark it dirty when
written, *without* a page fault.
I'm not convinced that it works completely correctly right now (I
suspect that there are some TLB flushing issues on the dirty->clean
transition), and it's likely prone to bit-rot, since the page cache
doesn't rely on it.
That being said, using hardware dirty tracking should be *much* faster
and less latency-inducing than doing it in software like this. It may
be worth trying to get HW dirty tracking working before adding more page
fault-based tracking.
(I think there's also some oddity on S/390. I don't know what that
oddity is or whether you should care.)
--Andy