[lkml]   [2000]   [Sep]   [12]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: 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).


To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
Please read the FAQ at

 \ /
  Last update: 2005-03-22 12:41    [W:0.107 / U:1.972 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site