Hi Andrea et al,
> 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.
I was thinking about writing a classic elevator simulation for tuning and
optimisation purposes, only I don't have (and can't get) any decent workload
captured. It would be great if someone could produce some ad hoc 'average'
workload. Obviously, there is not an average per se, but anything we could
play with. A bit like when David Miller was tuning the page cache hashing
function.
Anyone have any results I can get hold of?
- Dan
__________________________
Daniel J Blueman
Undergraduate - BSc Computing Science
UMIST university - Manchester
Direct line: 0161 933 3569
Mobile: 07775 583766
Email: daniel.j.blueman@stud.umist.ac.uk
SMS: daniel.j.blueman@sms.genie.co.uk
> >> [..] 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.
>
> >[..] 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. [..]
>
> Right (or more carefully: _possible_). For example that's obviously
> wrong if the long seek moves in another disk (raid hardware for example)
> and it may be wrong for some hardware but as said I was just supposing
> to learn the holdoff time with lowlevel blockdevice interaction.
>
> > [..] 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.
>
> The heuristic make sense only where we can give an hint and where we can't
> do readahead/readaround and that's the case of the indirect blocks. And
> even the indirect blocks case is an issue only during startup in only
> patological cases, then - once the indirect blocks are in cache - that's
not
> an issue anymore and so it doesn't even look like a real issue to me if
you
> have enough memory to take the very-hot informations in cache.
>
> >> 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
>
> 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, and the indirect
> blocks are going to be read only at once anyway as said above (and really
> binaries are usually too short to need to fault on lots of level of
> indirections so the heuristic is not going to help pageins at all).
>
> >> 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 :-)
>
> That's my whole point. If you fix the fs the heuristic is not necessary
> anymore.
>
> >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.
> ^^^^^^^^^^^^^^^^^^^^^^^^
>
-
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