Commit 7be02506 authored by Huan Yang's avatar Huan Yang Committed by Treehugger Robot
Browse files

BACKPORT: udmabuf: reuse folio array when pin folios



When invoke memfd_pin_folios, we need offer an array to save each folio
which we pinned.

The current way is dynamic alloc an array(use kvmalloc), get folios,
save into udmabuf and then free.

Depend on the size, kvmalloc can do something different:

Below PAGE_SIZE, slab allocator will be used, which have good alloc
performance, due to it cached page.

PAGE_SIZE - PCP Order, PCP(per-cpu-pageset) also given buddy page a
cache in each CPU, so different CPU no need to hold some lock(zone or
some) to get the locally page. If PCP cached page, the access also fast.

PAGE_SIZE - BUDDY_MAX, try to get page from buddy, due to kvmalloc adjusted
the gfp flags, if zone freelist can't alloc page(fast path), we will not
enter slowpath to reclaim memory. Due to need hold lock and check, may
slow, but still fast than vmalloc.

Anything wrong will fallback into vmalloc to alloc memory, it obtains
contiguous virtual addresses by loop alloc order 0 page(PAGE_SIZE), and
then map it into vmalloc area. If necessary, page alloc may enter
slowpath to reclaim memory. Hence, if fallback into vmalloc, it's slow.

When create, we need to iter each udmabuf item, then pin it's range
folios, if each item's range folio's count is large, we may fallback each
into vmalloc.

This patch find the largest range folio in items, then alloc this size's
folio array. When pin range folios, reuse this array.

Change-Id: Icaa4a3bbe983bdf7dabed5dc2419f678ae51bc00
Signed-off-by: default avatarHuan Yang <link@vivo.com>
Acked-by: default avatarVivek Kasireddy <vivek.kasireddy@intel.com>
Signed-off-by: default avatarVivek Kasireddy <vivek.kasireddy@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20240918025238.2957823-8-link@vivo.com


(cherry picked from commit c87a1268)
[TJ: Address conflicts with Jann's last 3 patches which already hit this
branch through stable. No functional changes.]
Bug: 389839576
Signed-off-by: default avatarT.J. Mercier <tjmercier@google.com>
parent f3c3f074
Loading
Loading
Loading
Loading
0% Loading or .
You are about to add 0 people to the discussion. Proceed with caution.
Please to comment