linux-stable/drivers/dma-buf
Jaewon Kim 3ccefdea22 dma-buf: system_heap: avoid reclaim for order 4
Using order 4 pages would be helpful for IOMMUs mapping, but trying to get
order 4 pages could spend quite much time in the page allocation.  From
the perspective of responsiveness, the deterministic memory allocation
speed, I think, is quite important.

The order 4 allocation with __GFP_RECLAIM may spend much time in reclaim
and compation logic.  __GFP_NORETRY also may affect.  These cause
unpredictable delay.

To get reasonable allocation speed from dma-buf system heap, use
HIGH_ORDER_GFP for order 4 to avoid reclaim.  And let me remove
meaningless __GFP_COMP for order 0.

According to my tests, order 4 with MID_ORDER_GFP could get more number
of order 4 pages but the elapsed times could be very slow.

         time	order 8	order 4	order 0
     584 usec	0	160	0
  28,428 usec	0	160	0
 100,701 usec	0	160	0
  76,645 usec	0	160	0
  25,522 usec	0	160	0
  38,798 usec	0	160	0
  89,012 usec	0	160	0
  23,015 usec	0	160	0
  73,360 usec	0	160	0
  76,953 usec	0	160	0
  31,492 usec	0	160	0
  75,889 usec	0	160	0
  84,551 usec	0	160	0
  84,352 usec	0	160	0
  57,103 usec	0	160	0
  93,452 usec	0	160	0

If HIGH_ORDER_GFP is used for order 4, the number of order 4 could be
decreased but the elapsed time results were quite stable and fast enough.

         time	order 8	order 4	order 0
   1,356 usec	0	155	80
   1,901 usec	0	11	2384
   1,912 usec	0	0	2560
   1,911 usec	0	0	2560
   1,884 usec	0	0	2560
   1,577 usec	0	0	2560
   1,366 usec	0	0	2560
   1,711 usec	0	0	2560
   1,635 usec	0	28	2112
     544 usec	10	0	0
     633 usec	2	128	0
     848 usec	0	160	0
     729 usec	0	160	0
   1,000 usec	0	160	0
   1,358 usec	0	160	0
   2,638 usec	0	31	2064

Link: https://lkml.kernel.org/r/20230303050332.10138-1-jaewon31.kim@samsung.com
Signed-off-by: Jaewon Kim <jaewon31.kim@samsung.com>
Reviewed-by: John Stultz <jstultz@google.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Johannes Weiner <hannes@cmpxchg.org>
Cc: Michal Hocko <mhocko@kernel.org>
Cc: Sumit Semwal <sumit.semwal@linaro.org>
Cc: T.J. Mercier <tjmercier@google.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2023-03-28 16:20:12 -07:00
..
heaps dma-buf: system_heap: avoid reclaim for order 4 2023-03-28 16:20:12 -07:00
dma-buf-sysfs-stats.c dma-buf: make kobj_type structure constant 2023-02-17 09:16:34 +01:00
dma-buf-sysfs-stats.h dma-buf: fix dma_buf_export init order v2 2022-12-13 08:31:45 +01:00
dma-buf.c Linux 6.2-rc6 2023-01-31 12:23:23 +01:00
dma-fence-array.c dma-buf: handle empty dma_fence_arrays gracefully 2022-03-29 09:14:30 +02:00
dma-fence-chain.c dma-buf: cleanup dma_fence_chain_walk 2022-05-30 11:24:50 +02:00
dma-fence-unwrap.c dma-buf: revert "return only unsignaled fences in dma_fence_unwrap_for_each v3" 2022-07-14 14:41:30 +02:00
dma-fence.c dma-buf: actually set signaling bit for private stub fences 2023-02-01 11:17:34 +01:00
dma-heap.c Driver Core changes for 6.2-rc1 2022-12-16 03:54:54 -08:00
dma-resv.c dma-buf: Proactively round up to kmalloc bucket size 2022-11-01 10:04:52 -07:00
Kconfig dma-buf: deprecate DMABUF_SYSFS_STATS 2022-06-23 10:51:43 +02:00
Makefile dma-buf: cleanup dma_fence_unwrap implementation 2022-05-30 14:16:32 +02:00
selftest.c
selftest.h
selftests.h dma-buf: add dma_fence_unwrap v2 2022-03-25 14:18:28 +01:00
st-dma-fence-chain.c treewide: use get_random_u32_inclusive() when possible 2022-11-18 02:18:02 +01:00
st-dma-fence-unwrap.c dma-buf: Enable signaling on fence for selftests 2022-09-16 15:53:25 +02:00
st-dma-fence.c dma-buf: Enable signaling on fence for selftests 2022-09-16 15:53:25 +02:00
st-dma-resv.c dma-buf: Enable signaling on fence for selftests 2022-09-16 15:53:25 +02:00
sw_sync.c
sync_debug.c
sync_debug.h
sync_file.c dma-buf/sync_file: use strscpy to replace strlcpy 2022-08-10 13:50:49 +02:00
sync_trace.h
udmabuf.c udmabuf: add vmap and vunmap methods to udmabuf_ops 2022-11-18 10:57:26 +01:00