Re: magic sysrq keys functionality

From: Matthias Andree <ma_at_dt.e-technik.uni-dortmund.de>
Date: Sat, 31 Jul 2004 12:51:08 +0200
John-Mark Gurney <gurney_j_at_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)
Received on Sat Jul 31 2004 - 08:52:35 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:38:04 UTC