linux-kernel - Re: [PATCH 4/8] io_uring/io-wq: cache work->flags in variable

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <19750632-1f9d-4075-ac5c-f44fab3690a6@gmail.com>
Date: Wed, 29 Jan 2025 23:41:57 +0000
From: Pavel Begunkov <asml.silence@...il.com>
To: Max Kellermann <max.kellermann@...os.com>
Cc: axboe@...nel.dk, io-uring@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 4/8] io_uring/io-wq: cache work->flags in variable

On 1/29/25 19:11, Max Kellermann wrote:
> On Wed, Jan 29, 2025 at 7:56 PM Pavel Begunkov <asml.silence@...il.com> wrote:
>> What architecture are you running? I don't get why the reads
>> are expensive while it's relaxed and there shouldn't even be
>> any contention. It doesn't even need to be atomics, we still
>> should be able to convert int back to plain ints.
> 
> I measured on an AMD Epyc 9654P.
> As you see in my numbers, around 40% of the CPU time was wasted on
> spinlock contention. Dozens of io-wq threads are trampling on each
> other's feet all the time.
> I don't think this is about memory accesses being exceptionally
> expensive; it's just about wringing every cycle from the code section
> that's under the heavy-contention spinlock.

Ok, then it's an architectural problem and needs more serious
reengineering, e.g. of how work items are stored and grabbed, and it
might even get some more use cases for io_uring. FWIW, I'm not saying
smaller optimisations shouldn't have place especially when they're
clean.

-- 
Pavel Begunkov