Messages in this thread | | | Date | Tue, 12 Sep 2000 16:46:32 +0200 (CEST) | From | Andrea Arcangeli <> | Subject | Re: More on 2.2.18pre2aa2 |
| |
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/
| |