On Sat, Nov 21, 2020 at 10:21:17AM -0800, Linus Torvalds wrote:
> So I think conceptually this is the right thing to do, but I have a
> couple of worries:
>
> - do we really need all those different versions? I'm thinking
> "iter_full" versions in particular. They I think the iter_full version
>
Jens Axboe wrote:
> which looks to be around a 6% drop.
That's quite a lot.
> which looks to be around 2-3%, but we're also running at a much
> slower rate (830K vs ~2.3M).
That's still a lot.
Thanks for having a look!
David
On 11/24/20 5:50 AM, David Howells wrote:
> Pavel Begunkov wrote:
>
>> fio is relatively heavy, I'd suggest to try fio/t/io_uring with nullblk
>
> no patches:
Here's what I get. nullb0 using blk-mq, and submit_queues==NPROC.
iostats and merging disabled, using 8k bs for t/io_uring to ensure we
Pavel Begunkov wrote:
> fio is relatively heavy, I'd suggest to try fio/t/io_uring with nullblk
no patches:
IOPS=885152, IOS/call=25/25, inflight=64 (64)
IOPS=890400, IOS/call=25/25, inflight=32 (32)
IOPS=890656, IOS/call=25/25, inflight=64 (64)
IOPS=896096, IOS/call=25/25, inflight=96 (96)
On 23/11/2020 10:31, David Howells wrote:
> Christoph Hellwig wrote:
>
>> Please run performance tests. I think the indirect calls could totally
>> wreck things like high performance direct I/O, especially using io_uring
>> on x86.
>
> Here's an initial test using fio and null_blk. I left
On 21/11/2020 14:31, Pavel Begunkov wrote:
> On 21/11/2020 14:13, David Howells wrote:
>> Switch to using a table of operations. In a future patch the individual
>> methods will be split up by type. For the moment, however, the ops tables
>> just jump directly to the old functions - which are
David Howells wrote:
> I tried three different sets of patches: none, just the first (which adds the
> jump table without getting rid of the conditional branches), and all of them.
And, I forgot to mention, I ran each test four times and then interleaved the
result lines for that set.
David
Christoph Hellwig wrote:
> Please run performance tests. I think the indirect calls could totally
> wreck things like high performance direct I/O, especially using io_uring
> on x86.
Here's an initial test using fio and null_blk. I left null_blk in its default
configuration and used the
On Sat, Nov 21, 2020 at 02:13:30PM +, David Howells wrote:
> Switch to using a table of operations. In a future patch the individual
> methods will be split up by type. For the moment, however, the ops tables
> just jump directly to the old functions - which are now static. Inline
>
From: David Howells
> Sent: 21 November 2020 14:14
>
> Switch to using a table of operations. In a future patch the individual
> methods will be split up by type. For the moment, however, the ops tables
> just jump directly to the old functions - which are now static. Inline
> wrappers are
From: Linus Torvalds
> Sent: 22 November 2020 19:22
> Subject: Re: [PATCH 01/29] iov_iter: Switch to using a table of operations
>
> On Sun, Nov 22, 2020 at 5:33 AM David Howells wrote:
> >
> > I don't know enough about how spectre v2 works to say if this would be a
> > problem for the ops-table
On Sun, Nov 22, 2020 at 5:33 AM David Howells wrote:
>
> I don't know enough about how spectre v2 works to say if this would be a
> problem for the ops-table approach, but wouldn't it also affect the chain of
> conditional branches that we currently use, since it's branch-prediction
> based?
No,
From: David Howells
> Sent: 22 November 2020 13:33
>
> Linus Torvalds wrote:
>
> > - I worry a bit about the indirect call overhead and spectre v2.
>
> I don't know enough about how spectre v2 works to say if this would be a
> problem for the ops-table approach, but wouldn't it also affect
Linus Torvalds wrote:
> - I worry a bit about the indirect call overhead and spectre v2.
I don't know enough about how spectre v2 works to say if this would be a
problem for the ops-table approach, but wouldn't it also affect the chain of
conditional branches that we currently use, since it's
On Sat, Nov 21, 2020 at 6:13 AM David Howells wrote:
>
> Switch to using a table of operations. In a future patch the individual
> methods will be split up by type. For the moment, however, the ops tables
> just jump directly to the old functions - which are now static. Inline
> wrappers are
On 21/11/2020 14:13, David Howells wrote:
> Switch to using a table of operations. In a future patch the individual
> methods will be split up by type. For the moment, however, the ops tables
> just jump directly to the old functions - which are now static. Inline
> wrappers are provided to
Switch to using a table of operations. In a future patch the individual
methods will be split up by type. For the moment, however, the ops tables
just jump directly to the old functions - which are now static. Inline
wrappers are provided to jump through the hooks.
Signed-off-by: David Howells
17 matches
Mail list logo
