Andrea Arcangeli 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 :).
The real time that matters is "I/O wakes up task, task runs and inserts
a new read into the queue".
That of course is entirely a function of CPU speed, but it would be
reasonable IMO to call it a small fixed time.
> >Andrea Arcangeli wrote:
> >> [..] (and waiting without knowing there will be a
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> >> near read veyr soon is not an option).[..]
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
As requested, I shall focus really hard on that sentence for a few
minutes :-)
....
> >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.
There should be a question: does the guess result in better overall I/O
performance?
I'm not sure. Waiting for a new request in the holdoff time only wins
if you get one and the elevator chooses it in preference to the request
that was waiting. And that may only happen in the same cases that
trigger readahead/readaround anyway.
> 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_.
Well _my_ point (;-) is that especially for page-ins, _nobody_ knows if
there will be another request soon. And that situation has another
property: there is a good chance that the next request from the paging
process will happen _really soon_ after it's woken up. Within just a
few instructions of being scheduled, it will fault, and that fault will
introduce an I/O.
Ok, there is scope for _clever_ readahead here by predicting access
sequences. But aside from that, there is still the question:
`` Does a small holdoff time improve the average throughput? ''
> >> 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).
No it's not related because that can be solved by fixing the fs :-)
Whereas holdoff for the request queue is elevator territory.
I'll finish by going back to: "Waiting for a new request in the holdoff
time only wins if you get one and the elevator chooses it in preference
to the request that was waiting. And that may only happen in the same
cases that trigger readahead/readaround anyway."
An exception is if I/O prioritisation is added, e.g. for interactive
process page-ins. Then the elevator would pick the priority request
even when its not local, and so the interactive process would get
interactive performance despite background I/O.
At the moment, that doesn't happen and background I/O will swamp even an
attempt at interactive priority I/O due to the device forever seeking.
have a nice day,
-- Jamie
-
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:16 EST