From: Chao Gao <chao.gao@intel.com>
To: <linux-kernel@vger.kernel.org>, <iommu@lists.linux.dev>
Cc: <dave.hansen@intel.com>, <len.brown@intel.com>,
<tony.luck@intel.com>, <rafael.j.wysocki@intel.com>,
<reinette.chatre@intel.com>, <dan.j.williams@intel.com>,
<kirill.shutemov@linux.intel.com>,
<sathyanarayanan.kuppuswamy@linux.intel.com>,
<ilpo.jarvinen@linux.intel.com>, <ak@linux.intel.com>,
<alexander.shishkin@linux.intel.com>
Subject: Re: [RFC v2 0/2] swiotlb performance optimizations
Date: Sat, 6 Aug 2022 03:55:18 +0800 [thread overview]
Message-ID: <Yu11pu7GwmV0Bf0V@gao-cwp> (raw)
In-Reply-To: <20220718012818.107051-1-chao.gao@intel.com>
Ping. Intel reviewers, comments and suggestions are welcome.
On Mon, Jul 18, 2022 at 09:28:16AM +0800, Chao Gao wrote:
>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.
>
>Results
>-------
>
>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(-)
>
>--
>2.25.1
>
prev parent reply other threads:[~2022-08-05 11:54 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-07-18 1:28 [RFC v2 0/2] swiotlb performance optimizations Chao Gao
2022-07-18 1:28 ` [RFC v2 1/2] swiotlb: use bitmap to track free slots Chao Gao
2022-07-18 1:28 ` [RFC v2 2/2] swiotlb: Allocate memory in a cache-friendly way Chao Gao
2022-08-05 19:55 ` Chao Gao [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=Yu11pu7GwmV0Bf0V@gao-cwp \
--to=chao.gao@intel.com \
--cc=ak@linux.intel.com \
--cc=alexander.shishkin@linux.intel.com \
--cc=dan.j.williams@intel.com \
--cc=dave.hansen@intel.com \
--cc=ilpo.jarvinen@linux.intel.com \
--cc=iommu@lists.linux.dev \
--cc=kirill.shutemov@linux.intel.com \
--cc=len.brown@intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=rafael.j.wysocki@intel.com \
--cc=reinette.chatre@intel.com \
--cc=sathyanarayanan.kuppuswamy@linux.intel.com \
--cc=tony.luck@intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).