From: Jens Axboe <axboe@kernel.dk>
To: Jann Horn <jannh@google.com>, Robin Murphy <robin.murphy@arm.com>,
Mark Rutland <mark.rutland@arm.com>,
Will Deacon <will.deacon@arm.com>,
Catalin Marinas <catalin.marinas@arm.com>
Cc: io-uring <io-uring@vger.kernel.org>
Subject: Re: [PATCH RFC] io_uring/rsrc: add last-lookup cache hit to io_rsrc_node_lookup()
Date: Wed, 30 Oct 2024 15:04:19 -0600 [thread overview]
Message-ID: <037d4950-d8f9-4a02-ba1a-d93f3cafd932@kernel.dk> (raw)
In-Reply-To: <CAG48ez3W+dkCerwioHNiZCWKJkuf9aL1s6SxN8X=yJ=JbGMB9Q@mail.gmail.com>
On 10/30/24 3:01 PM, Jann Horn wrote:
> On Wed, Oct 30, 2024 at 9:25?PM Jens Axboe <axboe@kernel.dk> wrote:
>> On 10/30/24 11:20 AM, Jann Horn wrote:
>>> On Wed, Oct 30, 2024 at 5:58?PM Jens Axboe <axboe@kernel.dk> wrote:
>>>> This avoids array_index_nospec() for repeated lookups on the same node,
>>>> which can be quite common (and costly). If a cached node is removed from
>>>
>>> You're saying array_index_nospec() can be quite costly - which
>>> architecture is this on? Is this the cost of the compare+subtract+and
>>> making the critical path longer?
>>
>> Tested this on arm64, in a vm to be specific. Let me try and generate
>> some numbers/profiles on x86-64 as well. It's noticeable there as well,
>> though not quite as bad as the below example. For arm64, with the patch,
>> we get roughly 8.7% of the time spent getting a resource - without it's
>> 66% of the time. This is just doing a microbenchmark, but it clearly
>> shows that anything following the barrier on arm64 is very costly:
>>
>> 0.98 ? ldr x21, [x0, #96]
>> ? ? tbnz w2, #1, b8
>> 1.04 ? ldr w1, [x21, #144]
>> ? cmp w1, w19
>> ? ? b.ls a0
>> ? 30: mov w1, w1
>> ? sxtw x0, w19
>> ? cmp x0, x1
>> ? ngc x0, xzr
>> ? csdb
>> ? ldr x1, [x21, #160]
>> ? and w19, w19, w0
>> 93.98 ? ldr x19, [x1, w19, sxtw #3]
>>
>> and accounts for most of that 66% of the total cost of the micro bench,
>> even though it's doing a ton more stuff than simple getting this node
>> via a lookup.
>
> Ah, actually... a difference between x86 and arm64 is that arm64 does
> an extra Speculative Data Barrier here, while x86 just does some
> arithmetic. Which I think is to work around "data value predictions",
> in which case my idea of using bitwise AND probably isn't valid.
>
> https://developer.arm.com/documentation/102816/0205/ section "Software
> Mitigations" says "Such code sequences are based around specific data
> processing operations (for example conditional select or conditional
> move) and a new barrier instruction (CSDB). The combination of both a
> conditional select/conditional move and the new barrier are sufficient
> to address this problem on ALL Arm implementations, both current and
> future".
Yep, see my followup on the x86-64 side too. Don't think it's worth
doing something just because it's expensive on arm64, in fact any kind
of higher frequency array_index_nospec() will be expensive on arm64 :/
--
Jens Axboe
prev parent reply other threads:[~2024-10-30 21:04 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-10-30 16:58 [PATCH RFC] io_uring/rsrc: add last-lookup cache hit to io_rsrc_node_lookup() Jens Axboe
2024-10-30 17:20 ` Jann Horn
2024-10-30 20:25 ` Jens Axboe
2024-10-30 20:52 ` Jens Axboe
2024-10-30 21:01 ` Jann Horn
2024-10-30 21:04 ` Jens Axboe [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=037d4950-d8f9-4a02-ba1a-d93f3cafd932@kernel.dk \
--to=axboe@kernel.dk \
--cc=catalin.marinas@arm.com \
--cc=io-uring@vger.kernel.org \
--cc=jannh@google.com \
--cc=mark.rutland@arm.com \
--cc=robin.murphy@arm.com \
--cc=will.deacon@arm.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.