Hi,
is there anything in the kernel that would allow an application to
*declare* that it needs disk read (or possibly) write bandwidth of n
KB/s?
The kernel would make every attempt to deliver that bandwidth, even
allowing starvation of other less important clients, except for some
5-10% headroom for emergency? I realise that the kernel cannot
*guarantee* that bandwidth, but some kind of priorization scheme would
help often enough, I guess.
I just lost another CD-R due to cron with lots and lots of on-disk
seeking kicking in, killing all that bandwidth cdrecord needed - and I
don't have one of these new and fancy burn-proof things (and, yes, I
should have suspended cron and friends, but I am only human and
computers are meant to made my life easier).
Sure, I could instruct cdrecord to increase its own read-ahead cache
from 4 MB to, say, 128 MB. But read-ahead cache != "QoS" (except for
volume of data == size of read-ahead cache), only a lame attempt at,
well, being helpful in an imperfect world.
>I just lost another CD-R due to cron with lots and lots of on-disk
>seeking kicking in, killing all that bandwidth cdrecord needed - and I
>don't have one of these new and fancy burn-proof things (and, yes, I
>should have suspended cron and friends, but I am only human and
>computers are meant to made my life easier).
>
>Sure, I could instruct cdrecord to increase its own read-ahead cache
>from 4 MB to, say, 128 MB. But read-ahead cache != "QoS" (except for
>volume of data == size of read-ahead cache), only a lame attempt at,
>well, being helpful in an imperfect world.
If you increase cdrecord's FIFO, you are giving it more time to
receive data, to refill the FIFO, and send the kernel a bigger
request. On an 8x writer, the 4Mb FIFO will empty in about 3.5
seconds, which is not enough for an IDE disk to process a queue of
seeks from the cronjob and return that quantity of data. If you give
it a decent-sized FIFO, for example 64Mb, you are giving it the
chance to:
- Request one piece of data (smallish) when the FIFO is first drained.
- Wait for a queue of seeks to complete and the first piece to be returned.
- During this time, the FIFO is being further drained... cdrecord
then sends off a request for the larger deficit which now exists.
- The kernel will process the new queue of seeks from the cronjob,
then hopefully return cdrecord's requested data all at once.
- The FIFO is still draining, to about twice the former level, but is
now replenished to the former level. cdrecord asks for the next
(large size) chunk of data.
The bottleneck in terms of latency is probably not the kernel, but
the IDE disk. It can only process seeks at a certain rate, and it
must return the data in-order due to the lame IDE spec (it need not
perform the actual seeks in order, but that's another story). Due to
the serialised nature of the cronjobs themselves, the kernel is
already putting cdrecord's requests fairly near the front of the
queue (even though they're actually at the back), so there's not a
great deal it can do to help.
Did I mention I have a 1993-built machine which can run an 8x writer
from it's original disk? The writer is no longer in that machine,
but it hardly matters. In both the old and new machines, I always
use a relatively large FIFO, just to be safe.
--
--------------------------------------------------------------
from: Jonathan "Chromatix" Morton
mail: [email protected] (not for attachments)
website: http://www.chromatix.uklinux.net/vnc/
geekcode: GCS$/E dpu(!) s:- a20 C+++ UL++ P L+++ E W+ N- o? K? w--- O-- M++$
V? PS PE- Y+ PGP++ t- 5- X- R !tv b++ DI+++ D G e+ h+ r++ y+(*)
tagline: The key to knowledge is not to rely on people to teach you it.