On 22/09/2020 07:22, Christoph Hellwig wrote:
On Mon, Sep 21, 2020 at 08:11:57PM +0100, Matthew Wilcox wrote:
This is awkward. I'd like it if we had a vfree() variant which called
put_page() instead of __free_pages(). I'd like it even more if we
used release_pages() instead of our own loop that called put_page().
Note that we don't need a new vfree variant, we can do this manually if
we want, take a look at kernel/dma/remap.c. But I thought this code
intentionally doesn't want to do that to avoid locking in the memory
for the pages array. Maybe the i915 maintainers can clarify.
+ Chris & Matt who were involved with this part of i915.
If I understood this sub-thread correctly, iterating and freeing the
pages via the vmapped ptes, so no need for a
shmem_read_mapping_page_gfp loop in shmem_unpin_map looks plausible to me.
I did not get the reference to kernel/dma/remap.c though, and also not
sure how to do the error unwind path in shmem_pin_map at which point the
allocated vm area hasn't been fully populated yet. Hand-roll the loop
walking vm area struct in there?
Regards,
Tvrtko
_______________________________________________
dri-devel mailing list
dri-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/dri-devel
