[PATCH v2 0/4] udmbuf bug fix and some improvements
Huan Yang
link at vivo.com
Mon Aug 5 03:25:42 UTC 2024
This patchset attempts to fix some errors in udmabuf and remove the
upin_list structure.
Some of this fix just gather the patches which I upload before.
Patch1,2,4 has passed the udmabuf self-test suite's tests.
Suggested by Kasireddy, Vivek <vivek.kasireddy at intel.com>
Test item 6 maybe requires running the command:
echo 1024 > /sys/kernel/mm/hugepages/hugepages-2048kB/nr_hugepages
Patch3 changed vmap, which can't simple test by testsuit.
But Patch4 restore vmap to the implementation before adding folio.
Patch1
===
Try to remove page fault mmap and direct map it.
Due to current udmabuf has already obtained and pinned the folio
upon completion of the creation.This means that the physical memory has
already been acquired, rather than being accessed dynamically. The
current page fault method only saves some page table memory.
As a result, the page fault mechanism has lost its purpose as a demanding
page. Due to the fact that page fault requires trapping into kernel mode
and filling in when accessing the corresponding virtual address in mmap,
this means that user mode access to virtual addresses needs to trap into
kernel mode.
Therefore, when creating a large size udmabuf, this represents a
considerable overhead.
Patch2
===
This is the same to patch:
https://lore.kernel.org/all/20240725021349.580574-1-link@vivo.com/
Patch3
===
The current implementation of udmabuf's vmap has issues.
It does not correctly set each page of the folio to the page structure,
so that when vmap is called, all pages are the head page of the folio.
This implementation is same as this patch:
https://lore.kernel.org/all/20240731090233.1343559-1-link@vivo.com/
Patch4
===
Attempt to remove unpin_list and other related data structures.
In order to adapt to Folio, we established the unpin_list data structure
to unpin all folios and maintain the page mapping relationship.
However, this data structure requires 24 bytes for each page and has low
traversal performance for the list. And maintaining the offset structure
also consumes a portion of memory.
This patch attempts to remove these data structures and modify the
semantics of some existing data structures.
udmabuf:
add folios -> folio array, which only contain's the folio, org contains
duplicate.
add foliocount -> folios array number
add pages -> page array, which contains pages which in folios, offset,
size determined by the offset of the memfd when udmabuf
created.
This patch also remove single folios' create on each create item, use it
be the ubuf->folios arrays' pointer, slide to fill the corresponding
folio under the item into the array.
Changelog
===
v2 -> v1:
Patch1, 3 Rectify the improper use of the sg table.
suggested-by Christian König <christian.koenig at amd.com>
Patch2 add acked-by Christian K�nig <christian.koenig at amd.com> which
marked in v1
Patch4
Modify the data structure to restore the use of pages and
correct the misunderstanding of loop conditions such as "pgcnt".
make sure pass self test.
remove v1's patch4
v1
https://lore.kernel.org/all/20240801104512.4056860-1-link@vivo.com/
Huan Yang (4):
udmabuf: cancel mmap page fault, direct map it
udmabuf: change folios array from kmalloc to kvmalloc
fix vmap_udmabuf error page set
udmabuf: remove folio unpin list
drivers/dma-buf/udmabuf.c | 207 ++++++++++++++------------------------
1 file changed, 78 insertions(+), 129 deletions(-)
base-commit: 048d8cb65cde9fe7534eb4440bcfddcf406bb49c
--
2.45.2
More information about the dri-devel
mailing list