From owner-svn-src-projects@FreeBSD.ORG Sun Aug 25 13:21:50 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 8298BCB5; Sun, 25 Aug 2013 13:21:50 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: from mail-ee0-x22e.google.com (mail-ee0-x22e.google.com [IPv6:2a00:1450:4013:c00::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id B6D382D76; Sun, 25 Aug 2013 13:21:49 +0000 (UTC) Received: by mail-ee0-f46.google.com with SMTP id c13so1116027eek.33 for ; Sun, 25 Aug 2013 06:21:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=pP0imFa8fGG6XKt3fxcCVaayKRcUlgKFJN2yCECb1ww=; b=wLRlWHjVUf01aeooxgaw2ZfuOFc3NN2UZ73I7hEAeeZOKALYjaZSjyVg48zakkpJI5 A41sm+a4U6wE3tazFX+j+p3HQ89OH2i4QN+kasifzYpBPd1ocTjEJSCFkoOQPVbPgPoE s+VVOv++gqeQhnRa+R9I+JQHojMkx1P2GzZNAlhaq7vCsC/ZoL6bAKdymScKig/9xxBf CIKTZPX30Zt9weG18XDdk4pOXKdpd3HeGzb1YhsrcAGlzjdHTJPTGN+GOKsdeumBglNT c55ybLQ9fkadUlKeslsMdmNBBHcqdNV8JB72GDR6lNZGHvP7j/5aT6o9+JVaIy2iydmj knZA== X-Received: by 10.14.214.136 with SMTP id c8mr16676584eep.6.1377436907668; Sun, 25 Aug 2013 06:21:47 -0700 (PDT) Received: from mavbook.mavhome.dp.ua ([37.229.21.195]) by mx.google.com with ESMTPSA id x47sm13953914eea.16.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 25 Aug 2013 06:21:46 -0700 (PDT) Sender: Alexander Motin Message-ID: <521A04E8.4010406@FreeBSD.org> Date: Sun, 25 Aug 2013 16:21:44 +0300 From: Alexander Motin User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130616 Thunderbird/17.0.6 MIME-Version: 1.0 To: Andre Oppermann 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> <5219F7EF.1050901@freebsd.org> In-Reply-To: <5219F7EF.1050901@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 13:21:50 -0000 On 25.08.2013 15:26, Andre Oppermann wrote: > 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? GEOM direct dispatch code is still very experimental and this change is an integral part of it. If there would be month or two ahead before slush, I would say there is a chance to merge both CAM and GEOM changes. But we are already in code slush state, so I doubt, unless I would be gives some official carte blanche and active help in code review and testing. While I think CAM locking changes are quite complete already, I still got no any real reviews for them 10 days after posting to the lists. :( GEOM changes I've done so far are quite small and are not breaking any KPI/KBI, only extending them, so they probably could be merged to 10-STABLE at any point later. CAM changes are much bigger and more invasive, but mostly for CAM internals. I haven't checked explicitly, but I hope that binary controller drivers compatibility should not be broken, so hopefully it also could be merged too. >> 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. Simple introduction of multiple worker threads to zvol could also help a lot for case of synchronous I/O. Somewhat less then direct dispatch, but that would be smaller and independent change. -- Alexander Motin