From owner-freebsd-current@FreeBSD.ORG Sat Jul 31 10:52:35 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BAA3316A4CE; Sat, 31 Jul 2004 10:52:35 +0000 (GMT) Received: from mail.dt.e-technik.uni-dortmund.de (mail.dt.E-Technik.Uni-Dortmund.DE [129.217.163.1]) by mx1.FreeBSD.org (Postfix) with ESMTP id BECFC43D5A; Sat, 31 Jul 2004 10:52:34 +0000 (GMT) (envelope-from ma@dt.e-technik.uni-dortmund.de) Received: from m2a2.dyndns.org (pD951F79E.dip.t-dialin.net [217.81.247.158]) 54F28287C6; Sat, 31 Jul 2004 12:51:09 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by merlin.emma.line.org (Postfix) with ESMTP id 9F626C378F; Sat, 31 Jul 2004 12:51:08 +0200 (CEST) Received: from merlin.emma.line.org ([127.0.0.1]) by localhost (m2a2.dyndns.org [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 09295-03-2; Sat, 31 Jul 2004 12:51:08 +0200 (CEST) Received: by merlin.emma.line.org (Postfix, from userid 500) id 709B5C3504; Sat, 31 Jul 2004 12:51:08 +0200 (CEST) To: Matthias Andree In-Reply-To: <20040728183132.GR991@funkthat.com> (John-Mark Gurney's message of "Wed, 28 Jul 2004 11:31:32 -0700") References: <1090718450.2020.4.camel@illusion.com> <200407251112.46183.doconnor@gsoft.com.au> <20040726175219.GA96815@green.homeunix.org> <20040726155712.R32601@pooker.samsco.org> <200407262220.i6QMKMT0098911@khavrinen.lcs.mit.edu> <20040728183132.GR991@funkthat.com> From: Matthias Andree Date: Sat, 31 Jul 2004 12:51:08 +0200 Message-ID: User-Agent: Gnus/5.110003 (No Gnus v0.3) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Virus-Scanned: by amavisd-new at m2a2.dyndns.org cc: Scott Long cc: current@FreeBSD.ORG cc: Garrett Wollman Subject: Re: magic sysrq keys functionality X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 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: Sat, 31 Jul 2004 10:52:35 -0000 John-Mark Gurney writes: > Matthias Andree wrote this message on Wed, Jul 28, 2004 at 11:44 +0200: >> Makes me wonder about efficiency (write latency). >> >> I admit I'm not familiar with how the buffers are scheduled in >> particular, if there are "write batches" or something. >> >> If however softdep needs to wait for individual blocks, real tagged >> queueing (with ordered tags in the right places and such) might be >> faster because the drive can then decide for itself in which order the >> blocks are written to the disks fastest, without violating any of the >> ordering assumptions softupdates code relies on. > > As another person said much more clearly... Softdep really does > dependancy tracking... As long as there are no outstanding writes > that it needs (like it can't write a data block till the block is > marked as in use, nor can it update the inode that the file uses that > data block, till the data is writen to disk) are still out standing, > it will submit the write request... so, if two blocks are not related > and have no oustanding dependancies, they will be scheduled and written > in parallel... and let the real tag queueing do it's work... I understand what softdep is doing, and I'm wondering about performance. An algorithm as you describe it cannot write two adjacent blocks in one rotation, let's assume block 171 depends on block 170, it would do: schedule block 170 for write wait until 170 is ack'd schedule block 171 for write With TCQ awareness, it could do instead: queue block 170 for write queue ordered tag queue 171 for write Whether the first or the second approach is faster with concurrent access, I cannot say, for I cannot benchmark the latter option as it isn't implemented and I cannot do it. -- Matthias Andree Encrypted mail welcome: my GnuPG key ID is 0x052E7D95 (PGP/MIME preferred)