Date: Tue, 23 Feb 2021 12:01:00 -0500 From: Alexander Motin <mav@FreeBSD.org> To: rgrimes@freebsd.org Cc: src-committers@freebsd.org, dev-commits-src-all@freebsd.org, dev-commits-src-main@freebsd.org Subject: Re: git: 7d4c444374d5 - main - Bump CTL block backend threads from 14 to 32 per LUN. Message-ID: <9a722455-7bc0-c10c-9a42-1650952475eb@FreeBSD.org> In-Reply-To: <202102231640.11NGeMsl017773@gndrsh.dnsmgr.net> References: <202102231640.11NGeMsl017773@gndrsh.dnsmgr.net>
next in thread | previous in thread | raw e-mail | index | archive | help
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@FreeBSD.org> >> AuthorDate: 2021-02-23 15:58:56 +0000 >> Commit: Alexander Motin <mav@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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?9a722455-7bc0-c10c-9a42-1650952475eb>