From owner-freebsd-scsi@FreeBSD.ORG Wed Sep 4 13:29:36 2013 Return-Path: Delivered-To: freebsd-scsi@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 5C9FFA0B; Wed, 4 Sep 2013 13:29:36 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: from mail-bk0-x236.google.com (mail-bk0-x236.google.com [IPv6:2a00:1450:4008:c01::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 311752412; Wed, 4 Sep 2013 13:29:34 +0000 (UTC) Received: by mail-bk0-f54.google.com with SMTP id mz12so167341bkb.41 for ; Wed, 04 Sep 2013 06:29:33 -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=KjWIzi+zzjy5EixOq84YnmeCwO5/zYJUl+xwaZAS7cg=; b=0wsCwn3GAC/ztaUAyTioLu8wt7jKdQkNpoOBKxI/fIxljCYeuc8fS7HSV/3AfYAiSJ nkcBy+X5TCHq8Qx4Vd8y2f/UGyUu5GXtOpu6H++c/hhoqnd3ulD1V0kyCFTFJu+o27mK CKfHvsuCNeUapbd/ry9rs829ItCJMdu3jUQrvq9dpbCZCfr79CRp+JXHrFM5Cz4TPYpI yqqtOFs51qPuwJ//NLlz8gF6D6xDhu6m1jeUfet2chJUAoTEUa7EZlfuL1zAmTTspHLo us5pLyZb6qWMBdEBR42rmbqV51Bw58/dJh40ko038vjbqhznKhY3yKY9pt2W9HRvmJJU 1Wqg== X-Received: by 10.205.22.71 with SMTP id qv7mr2518681bkb.20.1378301373128; Wed, 04 Sep 2013 06:29:33 -0700 (PDT) Received: from mavbook.mavhome.dp.ua ([37.229.21.195]) by mx.google.com with ESMTPSA id 14sm6560105bkl.17.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 04 Sep 2013 06:29:32 -0700 (PDT) Sender: Alexander Motin Message-ID: <522735B9.1070403@FreeBSD.org> Date: Wed, 04 Sep 2013 16:29:29 +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: Nathan Whitehorn Subject: Re: [RFC][CFT] GEOM direct dispatch and fine-grained CAM locking References: <520D4ADB.50209@FreeBSD.org> <5224511D.4090503@FreeBSD.org> <20130903134251.GB43281@caravan.chchile.org> <5226DAB0.1060303@FreeBSD.org> <52272B6F.9060308@freebsd.org> In-Reply-To: <52272B6F.9060308@freebsd.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Cc: freebsd-geom@freebsd.org, freebsd-hackers@freebsd.org, "freebsd-current@freebsd.org" , FreeBSD SCSI , =?windows-1252?Q?Olivier_Cochard-Labb=E9?= , Outback Dingo X-BeenThere: freebsd-scsi@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: SCSI subsystem List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Sep 2013 13:29:36 -0000 On 04.09.2013 15:45, Nathan Whitehorn wrote: > On 09/04/13 02:01, Alexander Motin wrote: >> On 04.09.2013 00:48, Olivier Cochard-Labbé wrote: >>> On Tue, Sep 3, 2013 at 8:10 PM, Outback Dingo >>> wrote: >>>> Can anyone confirm how well tested/stable this patch set might be?? if >>>> theres positive input i have a zoo of dev machines i could load it >>>> on, to >>>> help further it. >>>> Just checking to see how widely its been tested, >>> >>> I've installed this patch on 3 differents machines there status after >>> about 12hours: >>> - SUN FIRE X4170 M2 (amd64: r255178) with 6 SAS harddrives in one big >>> zraid (LSI MegaSAS Gen2 controller): Used for generating package with >>> poudriere… no probleme since; >>> - HAL/Fujitsu SPARC64-V (sparc64: r255178) with two SCSI-3 disks in >>> gmirror: Used for generating package with poudriere too… no probleme >>> since; >> >> I've forgot to mention, but GEOM direct dispatch is now active only on >> x86 because GET_STACK_USAGE macro now defined only there and I wanted >> to stay on a safe side. On other archs GEOM works in old queued way. >> Somebody should port that small macro to other archs. But that is >> still interesting data point. Thanks. > > Could you describe what this macro is supposed to do so that we can do > the porting work? It supposed to report total and used stack sizes for current thread. I suppose that it will be equal for the most archs, but better somebody familiar with each one looked on it. The macro itself is not new. It is for years used in Netgraph for equivalent purpose. -- Alexander Motin