> This is why deep tagged-queues are a bad idea.
Any queue ordering scheme will be at most as fair as FIFO, true, and
the deeper the queue is allowed to get the less fair it may become...
> When implemented correctly, as soon as there is contention for a
> resource like a disk, the kernel should prevent the process that is
> monopolizing the resource from using all the bandwidth. This could be
> accomplished by inserting an extra delay on, in this case, writing
> another block. Yes, this will mean that the disk starts to be idle
> some of the time. This is exactly what you want. My guess is that this
> algorithm should try to keep the disk idle for about 10% of the time.
Okay, so a busy nntpd should be denied the full bandwidth of the news
spool because root might log on some year and be impatient with a slow
response to "ls"? This is silly...especially in the case where the queue
depth is 0 and the putative hog is made to wait anyway. Unless the
hog is using async I/O or batching up a lot of writes, you're not going
to be able to notice a hog easily anyway without establishing histories...
and I'd much rather use that memory for write buffers.
Most disks, last I heard, prioritize reads over writes; if the kernel
did the same (or downprioritized just the buffered writes), interactive
performance should be just fine because either the interactive interloper
is doing a read or a synchronous write (in which case it gets handled
at least fairly quickly), or it's doing a bufferable write (which will
get buffered and allow the syscall to return immediately). All it
needs is a little aging mechanism to make sure old writes get presented
to the disk sometime this month.
Keith