From owner-freebsd-current@FreeBSD.ORG Wed Sep 4 08:20:13 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 7FC798FB; Wed, 4 Sep 2013 08:20:13 +0000 (UTC) (envelope-from joh.hendriks@gmail.com) Received: from mail-bk0-x233.google.com (mail-bk0-x233.google.com [IPv6:2a00:1450:4008:c01::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id D85322D5A; Wed, 4 Sep 2013 08:20:12 +0000 (UTC) Received: by mail-bk0-f51.google.com with SMTP id mx10so2533792bkb.38 for ; Wed, 04 Sep 2013 01:20:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=1DB8TmBk6vIZHTr6Fh8k8VeK+Qomdxu5G908UwKVwps=; b=Vb8ay+PLTgqCqyM000d/htxJrbUoFqIRg1qQEiq21DCW300UQALRnapCG29pa/3+sI Zgs1pbYpG3DPlO1Fuzsajk7rTVwGEG8q114xi0ylpxQkOaPuqsved7MMj+tEACBHd6If E6B/MQbM8itBjuteLWGwJ7/dq/OebCNGKfRbzBLpuf8X1ubz7fgwir7pRpi0A61wU6AX BISxASZ3B0QCgHMcBrtJcvcySqCN8ZKG1LDG2pZ3Akxo8u9qiqGapZCjD+TU8RrYGtra cuRzEhLGpYuEhN8tMFAXpT1d9H9RU7X//5tNfYTiaZANKGReL2DZv0fIK+R8AAUf9RPm fTBg== X-Received: by 10.204.162.74 with SMTP id u10mr239682bkx.47.1378282811083; Wed, 04 Sep 2013 01:20:11 -0700 (PDT) Received: from [192.168.1.129] ([193.173.55.180]) by mx.google.com with ESMTPSA id qx2sm5750721bkb.16.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 04 Sep 2013 01:20:10 -0700 (PDT) Message-ID: <5226ED39.3070200@gmail.com> Date: Wed, 04 Sep 2013 10:20:09 +0200 From: Johan Hendriks User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.0 MIME-Version: 1.0 To: Alexander Motin Subject: Re: [RFC][CFT] GEOM direct dispatch and fine-grained CAM locking References: <520D4ADB.50209@FreeBSD.org> <5224511D.4090503@FreeBSD.org> In-Reply-To: <5224511D.4090503@FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: FreeBSD X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Sep 2013 08:20:13 -0000 Alexander Motin wrote: > Hi. > > I would like to invite more people to review and test my patches for > improving CAM and GEOM scalability, that for last six months you could > see developing in project/camlock SVN branch. Full diff of that branch > against present head (r255131) can be found here: > http://people.freebsd.org/~mav/camlock_patches/camlock_20130902.patch > > Heavy CAM changes there were focused on reducing scope of SIM lock to > only protecting SIM internals, but not CAM core. That allows many > times reduce lock congestion, especially on heavily parallel request > submission with GEOM changes below. More detailed description of > changes you could see here earlier: > http://docs.freebsd.org/cgi/mid.cgi?520D4ADB.50209 > > GEOM changes were focused on avoiding switching to GEOM up/down > threads in relatively simple setups where respective classes don't > require it (and were explicitly marked so). That allows save on > context switches and on systems with several HBAs and disks talk to > them concurrently (that is where CAM locking changes are handy). Such > classes were modified to support it: DEV, DISK, LABEL, MULTIPATH, NOP, > PART, RAID (partially), STRIPE, ZERO, VFS, ZFS::VDEV, ZFS::ZVOL and > some others. Requests to/from other classes will be queued to GEOM > threads same as before. > > Together that allows to double block subsystem performance on high (at > least 100-200K) IOPS benchmarks, allowing to reach up to a million > total IOPS, while keeping full compatibility with all major ABIs/KBIs. > > Since we are already in 10.0 release process and changes are quite > big, my plan is to wait and commit them to head branch after the > freeze end, and then merge to stable/10. I hope the release process > will go on schedule to not delay this work for another six months. > > This work is sponsored by iXsystems, Inc. > Hello i would like to test this patch set. But how can i stress the machine, do you have a script or something i can use to make the system do heavy I/O on the disks! regards Johan