On Sat, 16 Sep 2000, Giuliano Pochini wrote:
> I wrote, then got air-brushed out of the thread?!
> > That's one approach; I prefer my "weighted scoring" approach. Supposing we
> > have three devices: a solid state disk (instant "seeks"), a hard drive and
> > a tape. The SSD will benefit from merges (fewer commands to process), but
> > not hugely - set both the metrics at 1, so a 64Kb request is just under
> > twice the "cost" of a 32Kb one. The hard drive can seek fairly quickly,
> > but long reads are preferable - say, seek_cost = 16, block_cost = 1. A
> > single 64Kb request is "cheaper" than a pair of 32Kb requests, but not
> > hugely so. Then the tape: seeks can take a few minutes, so make it
> > seek_cost = 65536, block_cost = 1: we don't really care how much is being
> > read, within reason, since seeks are so "expensive".
>
> If we could read by a SCSI command the maximun/typical/minimum seek and
> transfer speed directly from the drive things were a lot simpler :))
We can almost do that with any device; if we have a nice interface for
user-space tuning (a few /proc files), we can be told at boot-time what
the characteristics of each device are. A simple piece of code which does
a couple of seeks and a big read or two on each device would achieve this
easily enough.
We don't need to know the exact characteristics, but it could be of some
use in fine-tuning performance; my overall approach should work reasonably
well for any given device, I think?
James.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Sat Sep 23 2000 - 21:00:13 EST