[PATCH 1/4] nvme-tcp: per-controller I/O workqueues
Sagi Grimberg
sagi at grimberg.me
Wed Jul 3 12:41:38 PDT 2024
On 03/07/2024 22:17, Tejun Heo wrote:
> Hello,
>
> On Wed, Jul 03, 2024 at 10:14:14PM +0300, Sagi Grimberg wrote:
> ...
>> None of these reasons are the claimed reason to use separate workqueues in
>> this patch. The claim is that it is more efficient, i.e. has less overhead.
>>
>> The commit msg is the following:
>> "Implement per-controller I/O workqueues to reduce workqueue contention
>> during I/O."
> Hmm... it's not impossible for the concurrency accounting in pool_workqueues
> to show up if the issue rate is *really* high but I'd be surprised if that
> actually matters given that the backend pool is shared. Maybe I'm missing
> something but I don't see a reason why multiple workqueues would be more
> efficient than a shared one.
That was my assumption as well, that there is no real point in using
multiple workqueues.
And hence my surprise.
Hannes, can you please provide a quantitive improvement that you saw simply
by separating to different workqueues?
More information about the Linux-nvme
mailing list