On 2 Dec 2007, at 22:58, Eric Haszlakiewicz wrote:

> On Sun, Dec 02, 2007 at 06:34:40PM +0200, Jukka Marin wrote:
>> If I could limit the softdep flush to always keep some 10% of disk
>> I/O
>> available, the machine would not stop completely during the flush
>> operation.
>>
>> while (something_to_be_flushed) {
>>   if (systat_disk_%busy >= 90) {
>>     sleep_before_next_flush(a_bit);
>>   }
>>   flush_some_data();
>> };
>
> except what you really need is more like:
>
> while (something_to_be_flushed) {
>   if (systat_disk_%busy >= 90) {
> 	temporarily_let_new_io_bypass_softdep()
>   }
>   else
>     turn_off_bypass()
>   flush_some_data();
> };
>

I have my doubts that this will work without breaking the semantics
of softdep, which promises that after a crash
only certain inconsistencies exists (eg block still marked used but
free...).
At least it would add a lot of complexity.
What might be an option is to limited the rate write ops can hit the
queue when the queue length is big,
just delaying write ops slightly when a lot of them are outstanding.
But all this means a algorithmic pre-selection of what the io-
scheduler is suposed to do.

Or the syncer has to kick in earlier, this will slowdown the case
where everything fits into the cache and
can be flushed later but will prevent big delays and I doubt it has a
negative impact on overall performance,
where there aren't just short burst of io that fit into the cache
with enough pauses to get flushed in between.
(I think this is what the patch essentially did)

--

Viele Grüße,
Lars Heidieker

lars@heidieker.de
http://paradoxon.info

------------------------------------

Mystische Erklärungen.
Die mystischen Erklärungen gelten für tief;
die Wahrheit ist, dass sie noch nicht einmal oberflächlich sind.
      -- Friedrich Nietzsche

[demime 1.01d removed an attachment of type application/pgp-signature which had a name of PGP.sig]