git: 7d4c444374d5 - main - Bump CTL block backend threads from 14 to 32 per LUN.

[Alexander Motin]

On 23.02.2021 11:40, Rodney W. Grimes wrote:
>> The branch main has been updated by mav:
>>
>> URL: https://cgit.FreeBSD.org/src/commit/?id=7d4c444374d53e54ce197138df64bf40c1fb05a3
>>
>> commit 7d4c444374d53e54ce197138df64bf40c1fb05a3
>> Author:     Alexander Motin <mav at FreeBSD.org>
>> AuthorDate: 2021-02-23 15:58:56 +0000
>> Commit:     Alexander Motin <mav at FreeBSD.org>
>> CommitDate: 2021-02-23 16:03:32 +0000
>>
>>     Bump CTL block backend threads from 14 to 32 per LUN.
>>     
>>     This makes random read benchmarks look better on a wide ZFS pools.
>>     I am not sure where the original value goes from, but it is there
>>     for too long now.
> 
> I would think this should be bounded by the number of cores/threads
> in the system.  What happens on a 4 thread system with this value?

Since our VFS layer is still synchronous, the primary goal of these
threads is to wait for disk I/O.  And 4 thread system with HDDs should
still benefit from higher value.  For SSD system CPUs may become a
bottleneck, but it would just speak about under-powered system.

My biggest worry is a random locks contention from double number of
threads.  Not many algorithms scale to 32 threads on small I/Os and very
high IOP.  But that is theoretical, while on wide pool of slower HDDs I
do see double performance from this right now.

-- 
Alexander Motin