[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <785d1da7-cf19-4f7b-a356-853e35992f82@meta.com>
Date: Mon, 17 Mar 2025 10:32:02 +0000
From: Mark Harmstone <maharmstone@...a.com>
To: Pavel Begunkov <asml.silence@...il.com>,
Sidong Yang
<sidong.yang@...iosa.ai>,
Josef Bacik <josef@...icpanda.com>, David Sterba
<dsterba@...e.com>,
Jens Axboe <axboe@...nel.dk>
CC: "linux-btrfs@...r.kernel.org" <linux-btrfs@...r.kernel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"io-uring@...r.kernel.org" <io-uring@...r.kernel.org>
Subject: Re: [RFC PATCH v3 0/3] introduce io_uring_cmd_import_fixed_vec
On 16/3/25 07:22, Pavel Begunkov wrote:
> >
> On 3/15/25 17:23, Sidong Yang wrote:
>> This patche series introduce io_uring_cmd_import_vec. With this function,
>> Multiple fixed buffer could be used in uring cmd. It's vectored version
>> for io_uring_cmd_import_fixed(). Also this patch series includes a usage
>> for new api for encoded read/write in btrfs by using uring cmd.
>>
>> There was approximately 10 percent of performance improvements through
>> benchmark.
>> The benchmark code is in
>> https://github.com/SidongYang/btrfs-encoded-io-test/blob/main/main.c
>> ./main -l
>> Elapsed time: 0.598997 seconds
>> ./main -l -f
>> Elapsed time: 0.540332 seconds
>
> It's probably precise, but it's usually hard to judge about
> performance from such short runs. Mark, do we have some benchmark
> for the io_uring cmd?
Unfortunately not. My plan was to plug it in to btrfs-receive and to use
that as a benchmark, but it turned out that the limiting factor there
was the dentry locking.
Sidong, Pavel is right - your figures would be more useful if you ran it
1,000 times or so.
Mark
Powered by blists - more mailing lists