Hi Andrea :-)
> >Andrea Arcangeli wrote:
> >> [..] 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?
>
> No if you don't know there will be another near request as soon as the
> current one gets completed.
I don't know how you reach this conclusion. Can you explain?
I can see that if you never receive requests during holdoff then of
course you lose. That's why you choose a very small holdoff time -- one
which is small compared with the expected seek time. (E.g. 50 times
smaller).
I can also see that if you do receive some requests during holdoff, then
throughput can be much faster. Explanation follows.
> >[..] 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.
>
> As just said readahead(read(2))/readaround(pageins) by design doesn't need
> such logic at all. They instead invalidate the benefit of that heuristic.
That's what I meant. We agree -- there is no need for special elevator
logic to improve readahead :-)
> >Well _my_ point (;-) is that especially for page-ins, _nobody_ knows if
> >there will be another request soon. And that situation has another
>
> The pagein has to discover where the binary data block is. To do that you
> may have to follow indirect blocks. So really the heuristic can fit inside
> pageins too.
>
> For the binary _data_, the readaround takes care of that,
Here's where I disagree. Holdoff is proposed to take care of the
specific cases where readaround _doesn't_ work. Holdoff doesn't help at
all when readaround is working ok.
This is for those cases where a program calls some function that needs
to be paged in (along with its supporting functions), and that pulls in
code and data from 20 different places in the executable.
> >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.
> ^^^^^^^^^^^^^^^^^^^^^^^^
>
> You are definitely talking about 2.2.x. 2.3.x recognizes pageins and puts
> them at the top of the queue despite of the background I/O. Try and give
> me testcases (instead of words :) if that's not true. Interactiveness is
> just fine in 2.3.49 (on IDE at least) as far I can tell.
Heh, testcases. Let's stick to theory for today, ok? :-)
Putting pageins at the top of the queue isn't enough. It doesn't
prevent seeks from dominating I/O time due to competition between
processes.
(Quite apart from "interactive", which IMO should be recognised and
given higher I/O priority for as long as they're classified that way).
Here's the theoretical example.
Scenario: I/O- and memory-loaded machine and you start Emacs. Assume
readaround is "5" blocks for purpose of example, but Emacs likes to
touch pages spread of
Version without holdoff
-----------------------
Emacs Background
----- ----------
Req. read block 30
Req. read block 1000
Block 30 completes
Start 1000
Req. read block 40
Block 1000 completes
Start block 40
Req. read block 1010
Block 40 completes
Start 1010
Req. read block 20
Block 1010 completes
Start block 20
Req. read block 1020
Block 20 completes
Start 1020
Req. read block 10
Block 1020 completes
Start block 10
Req. read block 1030
Block 10 completes
Start 1030
Req. read block 50
Block 1030 completes
Start block 50
Req. read block 1040
Block 50 completes
...
Version with holdoff
--------------------
Emacs Background
----- ----------
Req. read block 30
Req. read block 1000
Block 30 completes
Start 1000 with 100us holdoff
Req. read block 40 in less than 100us
Start block 40
Block 40 completes
Start 1000 with 100us holdoff
Req. read block 20 in less than 100us
Start block 20
Block 20 completes
Start 1000 with 100us holdoff
Req. read block 10 in less than 100us
Start block 10
Block 10 completes
Start 1000, fairness says it has waited enough
Req. read block 50
Block 1000 completes
Start 50, immediate because it's pagein
Block 50 completes
Req. read block 1010
Start block 1010
Block 1010 completes
Start block 1020
Block 1020 completes
Start 50 with 100us holdoff
Start block 1030
Block 1030 completes
Req. read block 1040
...
Results
-------
This is the result.
Read sequence without holdoff: 30, 1000, 40, 1010, 20, 1020, 10, 1030, 50...
Read sequence with holdoff: 30, 40, 20, 10, 1000, 50, 1010, 1020, 1030...
Paging time: holdoff wins.
...because it can cluster, the paging process runs faster.
Overall throughput: holdoff wins.
...because of seek times, everyone gets better throughput.
> The reason in 2.3.49 you are not getting the bad seek behaviour you are
> worried about is thanks to readahead/around and thanks to the cache that
> let us to fault in the indirection blocks only once in a while.
You're right, readahead and readaround are pretty good. But there are
definitely situations where they don't work too well. Try starting
Netscape from cold cache with a few "find /"s running in the
background. It's not too slow, but it's definitely slower. I'd like
the finds to
> Again: if you have real life seek problems with 2.3.49 let me know and I'll
> be glad to work to fix them, but I currently don't buy the holdoff time
> betweek large seeks as a solution for the seeks since it would harm
> too much the common case and for the indirect blocks with fs interaction case
> it seems not worty enough.
Forget about indirect blocks. You may have a point, but I don't care
about indirect blocks at all. I'm thinking entirely about the
"interactive user experience under load", and that means things like
starting applications while the disk is busy.
> I can certainly change idea in the future if real life prove I am
> wrong, but that's my current opinion with the picture I have in mind.
Yeah. It's happened before :-)
have 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