Date: Sun, 25 Aug 2013 14:26:23 +0200 From: Andre Oppermann <andre@freebsd.org> To: Alexander Motin <mav@FreeBSD.org> Cc: svn-src-projects@freebsd.org, src-committers@freebsd.org Subject: Re: svn commit: r254846 - projects/camlock/sys/cddl/contrib/opensolaris/uts/common/fs/zfs Message-ID: <5219F7EF.1050901@freebsd.org> In-Reply-To: <5219F4A9.2090501@FreeBSD.org> References: <201308251121.r7PBLA3v033536@svn.freebsd.org> <5219F4A9.2090501@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On 25.08.2013 14:12, Alexander Motin wrote: > On 25.08.2013 14:21, Alexander Motin wrote: >> Author: mav >> Date: Sun Aug 25 11:21:10 2013 >> New Revision: 254846 >> URL: http://svnweb.freebsd.org/changeset/base/254846 >> >> Log: >> Allow GEOM direct dispatch for zvol providers. Skip request handover to >> the worker thread if current context allows sleeping (thanks to the direct >> dispatch in action we are not in GEOM thread). >> >> Together this doubles zvol performance, reaching up to 300K IOPS on my tests. >> If there would be unmapped I/O support for zvols, the above value could be >> even bigger. > > I heavily underestimated effect of this change for the case of uncached reads and probably > synchronous writes. Due to synchronous nature of the code, parallel execution introduced by this > change can increase performance by much more then mentioned two times. With 8-64 threads doing > uncached random read this change gives 6-10x performance! Any chance for this to make it into HEAD before API freeze? > Now I am very curios why zvol was made to have only one worker thread per zvol, while multiple > threads there could give major improvement even without direct dispatch. -- Andre
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?5219F7EF.1050901>