On Tue, 12 Sep 2000, Jamie Lokier wrote:
>Sure the global system is slower. But the "interactive feel" is faster.
>If I type "find /" I want it to go quickly. But I still want Emacs to
You always want it to go quickly. But when you're in the blockdevice
layer you lost all the semantics of such I/O request. You have no idea if
somebody is running a background `cp` or if it's your `find` that's doing
the I/O.
>start up in a reasonable time, even if that means the overall time for
>both processes is slower.
And you as well want your `cp` not to run two times slower, right?
Then you have to choose. And you can choose with elvtune. (currently you
have to choose per blockdevice basis, maybe in the future you'll be able
to choose per 'struct file' basis)
That's not a matter of the algorithm. The only difference between the "in
function of time latency" and "in function of blocksize latency" is that
in kernel space we don't need to know the internal timings of the
hardware. If you know the timings and you want a 2 second latency
(assuming your harddisk write 1 block in less than 2 seconds) that do the
calc in userspace and run the blkelvset ioctl and you're almost happy. You
won't be completly happy because as said the elevator will give a two
seconds latency also to requests that are at the end of the queue, but
this is a matter of the algorithm, not really of the unit of measure of
the latency in kernel space.
The current unit of measure allows us to use the same latency settings for
most devices out there and still providing a good throughput (and avoiding
huge stalls). That's why I prefer it. But you can convert it easily in
userspace (or even you can change the unit in kernel but I don't see the
advantage, I'd rather prefer elvtune to do the conversion and to talk in
function of time instead of putting the timing stuff into the kernel).
Andrea
-
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 : Fri Sep 15 2000 - 21:00:18 EST