From owner-freebsd-current@FreeBSD.ORG Sun Mar 21 19:14:43 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4FF47106564A; Sun, 21 Mar 2010 19:14:43 +0000 (UTC) (envelope-from julianelischer@gmail.com) Received: from mail-gw0-f54.google.com (mail-gw0-f54.google.com [74.125.83.54]) by mx1.freebsd.org (Postfix) with ESMTP id CC95A8FC08; Sun, 21 Mar 2010 19:14:42 +0000 (UTC) Received: by gwj15 with SMTP id 15so2605465gwj.13 for ; Sun, 21 Mar 2010 12:14:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=+toFUVuysJTKGI6mHO1fI+e5Mp83VbA6/PyJPof96cQ=; b=Ru4G6j89dTAYDrOuyslHkZIUVhvNHFmLuARg6oPrMxRCCvsPtE1SR7jZlVQeeJuowW cEcUIMv8UblwNejsoJ4YQkZQAVaQ7vG8b/K4yO7AIcSe4Dg3OkP80zBey/4E8/6Wm/Cl 58JioF4/6DuutmarEQxvWKcf0VX+vpcMksJsc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=l2GIF0+dBVWiMr3zvPQWT12pQbqwsnSHnGEA+j8QmdftSbp3J4o9yg8p970o1B2FgG E5SYzlhIM+vAOsgdZNpaI5no9gGLocSusJo3Om+bAXD9nmvs2AXtB+/r9P4rgZjoE0Mn +23tT7MCrUDo9dJfU7WXgsFL7MFwPoixPHmM8= Received: by 10.90.18.33 with SMTP id 33mr3236754agr.12.1269197000835; Sun, 21 Mar 2010 11:43:20 -0700 (PDT) Received: from julian-mac.elischer.org (h-67-100-89-137.snfccasy.static.covad.net [67.100.89.137]) by mx.google.com with ESMTPS id 7sm1276334ywc.4.2010.03.21.11.43.19 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sun, 21 Mar 2010 11:43:20 -0700 (PDT) Sender: Julian Elischer Message-ID: <4BA668C9.5080407@elischer.org> Date: Sun, 21 Mar 2010 11:43:21 -0700 From: Julian Elischer User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: Scott Long References: <1269109391.00231800.1269099002@10.7.7.3> <1269120182.00231865.1269108002@10.7.7.3> <1269120188.00231888.1269109203@10.7.7.3> <1269123795.00231922.1269113402@10.7.7.3> <1269130981.00231933.1269118202@10.7.7.3> <1269130986.00231939.1269119402@10.7.7.3> <1269134581.00231948.1269121202@10.7.7.3> <1269134585.00231959.1269122405@10.7.7.3> <4BA6279E.3010201@FreeBSD.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Alexander Motin , freebsd-current@freebsd.org, Ivan Voras , freebsd-arch@freebsd.org Subject: Re: Increasing MAXPHYS X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 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: Sun, 21 Mar 2010 19:14:43 -0000 Scott Long wrote: > I agree that more threads just creates many more race > complications. Even if it didn't, the storage driver is a > serialization point; it doesn't matter if you have a dozen g_* > threads if only one of them can be in the top half of the driver at > a time. No amount of fine-grained locking is going to help this. Well that depends on the driver and device.. We have multiple linux threads coming in the top under some setups so it wouldn't be a problem. > > I'd like to go in the opposite direction. The queue-dispatch-queue > model of GEOM is elegant and easy to extend, but very wasteful for > the simple case, where the simple case is one or two simple > partition transforms (mbr, bsdlabel) and/or a simple stripe/mirror > transform. None of these need a dedicated dispatch context in > order to operate. What I'd like to explore is compiling the GEOM > stack at creation time into a linear array of operations that > happen without a g_down/g_up context switch. As providers and > consumers taste each other and build a stack, that stack gets > compiled into a graph, and that graph gets executed directly from > the calling context, both from the dev_strategy() side on the top > and the bio_done() on the bottom. GEOM classes that need a > detached context can mark themselves as such, doing so will prevent > a graph from being created, and the current dispatch model will be > retained. I've considered similar ideas. Or providing a non-queuing options for some simple transformations. > > I expect that this will reduce i/o latency by a great margin, thus > directly addressing the performance problem that FusionIO makes an > example of. I'd like to also explore having the g_bio model not > require a malloc at every stage in the stack/graph; even though > going through UMA is fairly fast, it still represents overhead that > can be eliminated. It also represents an out-of-memory failure > case that can be prevented. > > I might try to work on this over the summer. It's really a > research project in my head at this point, but I'm hopeful that > it'll show results. > > Scott > > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current To > unsubscribe, send any mail to > "freebsd-current-unsubscribe@freebsd.org"