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
| ||
|
Date: Tue, 14 Jul 2020 10:15:32 +0300 From: Pavel Begunkov <asml.silence@...il.com> To: Jens Axboe <axboe@...nel.dk>, io-uring@...r.kernel.org, linux-kernel@...r.kernel.org Subject: Re: [PATCH 0/5] batch completion + freeing improvements On 14/07/2020 04:08, Jens Axboe wrote: > On 7/13/20 5:41 PM, Pavel Begunkov wrote: >> Different batching improvements, that's it. >> >> Unfortunately, I don't have a decent SSD/setup at hand to >> benchmark it properly. > > I do though, but I'm not seeing any improvement with this, whereas > some of the previous series made nice improvements... If anything > maybe it's a bit slower. Thanks for testing it, appreciate that. Probably, the array did something wrong with your caches, or the 2-step approach is to blame. I'll try to refine and/or resend parts after closer benchmarking. > >> p.s. if extra 32 pointers on stack would be a problem, I wanted for >> long to put submit_state into ctx itself. > > It's getting up there... But really depends on how early in the stack, > so 32 could _probably_ work, though usually batched on-stack counts > are a bit lower than that. On a fresh head 250 bytes looks too much, I agree. That considering that io_uring is stacking on top of vfs or near that, and there are already fast_iovec/msg. -- Pavel Begunkov
Powered by blists - more mailing lists