From owner-svn-src-projects@FreeBSD.ORG Sun Aug 25 12:26:37 2013 Return-Path: Delivered-To: svn-src-projects@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 2D58C9B7 for ; Sun, 25 Aug 2013 12:26:37 +0000 (UTC) (envelope-from andre@freebsd.org) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 93FD42B1B for ; Sun, 25 Aug 2013 12:26:36 +0000 (UTC) Received: (qmail 666 invoked from network); 25 Aug 2013 13:08:58 -0000 Received: from c00l3r.networx.ch (HELO [127.0.0.1]) ([62.48.2.2]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 25 Aug 2013 13:08:58 -0000 Message-ID: <5219F7EF.1050901@freebsd.org> Date: Sun, 25 Aug 2013 14:26:23 +0200 From: Andre Oppermann User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: Alexander Motin Subject: Re: svn commit: r254846 - projects/camlock/sys/cddl/contrib/opensolaris/uts/common/fs/zfs References: <201308251121.r7PBLA3v033536@svn.freebsd.org> <5219F4A9.2090501@FreeBSD.org> In-Reply-To: <5219F4A9.2090501@FreeBSD.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: svn-src-projects@freebsd.org, src-committers@freebsd.org X-BeenThere: svn-src-projects@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "SVN commit messages for the src " projects" tree" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Aug 2013 12:26:37 -0000 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