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 <[email protected]> >> AuthorDate: 2021-02-23 15:58:56 +0000 >> Commit: Alexander Motin <[email protected]> >> 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 _______________________________________________ [email protected] mailing list https://lists.freebsd.org/mailman/listinfo/dev-commits-src-all To unsubscribe, send any mail to "[email protected]"
