[lkml]   [2022]   [Jul]   [17]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
Subject[RFC v2 0/2] swiotlb performance optimizations
Intent of this post:
Seek reviews from Intel reviewers and anyone else in the list
interested in IO performance in confidential VMs. Need some acked-by
reviewed-by tags before I can add swiotlb maintainers to "to/cc" lists
and ask for a review from them.

Changes from v1 to v2:
- rebase to the latest dma-mapping tree.
- drop the duplicate patch for mitigating lock contention
- re-collect perf data

swiotlb is now widely used by confidential VMs. This series optimizes
swiotlb to reduce cache misses and lock contention during bounce buffer
allocation/free and memory bouncing to improve IO workload performance in
confidential VMs.

Here are some FIO tests we did to demonstrate the improvement.

Test setup

A normal VM with 8vCPU and 32G memory, swiotlb is enabled by swiotlb=force.
FIO block size is 4K and iodepth is 256. Note that a normal VM is used so
that others lack of necessary hardware to host confidential VMs can reproduce
results below.


1 FIO job read/write IOPS (k)
vanilla read 216
write 251
optimized read 250
write 270

1-job FIO sequential read/write perf increase by 19% and 8% respectively.

Chao Gao (2):
swiotlb: use bitmap to track free slots
swiotlb: Allocate memory in a cache-friendly way

include/linux/swiotlb.h | 8 ++-
kernel/dma/swiotlb.c | 127 +++++++++++++++++-----------------------
2 files changed, 60 insertions(+), 75 deletions(-)


 \ /
  Last update: 2022-07-18 03:29    [W:0.032 / U:0.664 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site