Skip site navigation (1)Skip section navigation (2)
Date:      Sat, 31 Jul 2004 12:51:08 +0200
From:      Matthias Andree <ma@dt.e-technik.uni-dortmund.de>
To:        Matthias Andree <ma@dt.e-technik.uni-dortmund.de>
Cc:        Garrett Wollman <wollman@khavrinen.lcs.mit.edu>
Subject:   Re: magic sysrq keys functionality
Message-ID:  <m3llh0sb4z.fsf@merlin.emma.line.org>
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> <m3hdrulbfk.fsf@merlin.emma.line.org> <20040726155712.R32601@pooker.samsco.org> <200407262220.i6QMKMT0098911@khavrinen.lcs.mit.edu> <m31xiw8nzo.fsf@merlin.emma.line.org> <20040728183132.GR991@funkthat.com>

next in thread | previous in thread | raw e-mail | index | archive | help
John-Mark Gurney <gurney_j@resnet.uoregon.edu> 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)



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?m3llh0sb4z.fsf>