On Thu, 9 Mar 2000, Jamie Lokier wrote:
> [..] But note,
>that the minimum useful holdoff time is also a function of the CPU
>speed:[..]
Of course but the CPU speed is a minor cost (unless you run on a
ramdisk and in such case the heuristic should be disabled in first
place since seeks are no cost there :).
>Andrea Arcangeli wrote:
>> [..] (and waiting without knowing there will be a
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>> near read veyr soon is not an option).[..]
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
*snip*
>I think you misunderstand. A hint is something completely different. [..]
Please focus on my above sentence. Waiting time without knowing there will
be a request is a no-way IMHO. Any kind of guess will lose and will harm
the fast path.
I remember you said the larger the seek is, the more probability another
request will happen in the middle. Ok. But the whole point is that you
_can't_ know if there will be another request any time soon unless the fs
tells you about that. The FS is the only entity that can know that
_sometime_.
>> And implementing extents in the filesystem is going to take care of the
>> indirect blocks issue anyway.
>
>But not the issue I'm talking about.
It's related IMHO because that's nearly the only place where we can't do
readahead and where we do "near" sync requests at regular intervals
(read, wait, read next, wait, read next).
Andrea
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Wed Mar 15 2000 - 21:00:15 EST