On Mon, 2 Sept 2024 at 03:34, Christian König <christian.koenig@xxxxxxx> wrote:
>
> Am 02.09.24 um 11:32 schrieb Thomas Hellström:
> >
> > The remap_pfn_range was last tried, at least in the context of the i915
> > driver IIRC by Christoph Hellwig but had to be ripped out since it
> > requires the mmap_lock in write mode. Here we have it only in read
> > mode.
Yeah, that does make things much more fragile. The "fill in multiple
pages" helpers are really meant to be used at mmap() time, not as some
kind of fault-around.
So remap_pfn_range() sets the vma flags etc, but it also depends on
being the only one to fill in the ptes, and will be *very* unhappy if
it finds something that has already been filled in.
And fault-around is *much* more fragile because unlike the mmap time
thing, it can happen concurrently with other faults, and you cannot
make assumptions about existing page table layout etc.
> The pre-faulting was increased because of virtualization. When KVM/XEN
> is mapping a BO into a guest the switching overhead for each fault is so
> high that mapping a lot of PFNs at the same time becomes beneficial.
Honestly, from a pure performance standpoint, if you can just do all
the page mapping at mmap() time, that would be *much* much better.
Then you can easily use that remap_pfn_range() function, and latencies
are much less of an issue in general (not because it would be any
faster, but simply because people don't tend to use mmap() in
latency-critical code - but taking a page fault is *easily* very
critical indeed).
Linus
