[LSF/MM/BPF TOPIC] Improving Zoned Storage Support
Bart Van Assche
bvanassche at acm.org
Wed Jan 17 12:18:01 PST 2024
On 1/17/24 12:06, Jens Axboe wrote:
> Case in point, I spent 10 min hacking up some smarts on the insertion
> and dispatch side, and then we get:
>
> IOPS=2.54M, BW=1240MiB/s, IOS/call=32/32
>
> or about a 63% improvement when running the _exact same thing_. Looking
> at profiles:
>
> - 13.71% io_uring [kernel.kallsyms] [k] queued_spin_lock_slowpath
>
> reducing the > 70% of locking contention down to ~14%. No change in data
> structures, just an ugly hack that:
>
> - Serializes dispatch, no point having someone hammer on dd->lock for
> dispatch when already running
> - Serialize insertions, punt to one of N buckets if insertion is already
> busy. Current insertion will notice someone else did that, and will
> prune the buckets and re-run insertion.
>
> And while I seriously doubt that my quick hack is 100% fool proof, it
> works as a proof of concept. If we can get that kind of reduction with
> minimal effort, well...
If nobody else beats me to it then I will look into using separate
locks in the mq-deadline scheduler for insertion and dispatch.
Bart.
More information about the Linux-nvme
mailing list