On Sun, 26 Aug 2001, Victor Yodaiken wrote:
> On Sun, Aug 26, 2001 at 04:38:55PM -0300, Rik van Riel wrote:
> > On Sun, 26 Aug 2001, Victor Yodaiken wrote:
> >
> Daniel was suggesting a readahead thread, if I'm not mistaken.
Ouch, that's about as insane as it gets ;)
> > > BTW: maybe I'm oversimplifying, but since read-ahead is an optimization
> > > trading memory space for time, why doesn't it just turn off when there's
> > > a shortage of free memory?
> > > num_pages = (num_requestd_pages + (there_is_a_boatload_of_free_space? readahead: 0)
> >
> > When the VM load is high, the last thing you want to do is
> > shrink the size of your IO operations, this would only lead
> > to more disk seeks and possibly thrashing.
>
> Doesn't this very much depend on why VM load is high and on the
> kind of I/O load? For example, if your I/O load is already in
> big chunks or if VM stress is being caused by a bunch of big
> threads hammering shared data that is in page cache already.
Processes accessing stuff already in RAM aren't causing
any VM stress, since all the stuff they need is already
in RAM.
As for I/O already being done in big chunks, I'm not sure
if readahead would have any influence on this situation.
> At least to me, "thrashing" where the OS is shuffling pages in and
> out without work getting done is different from "thrashing" where
> user processes run with suboptimal I/O.
Actually, "suboptimal I/O" and "shuffling pages without getting
work done" are pretty similar.
> > It would be nice to do something similar to TCP window
> > collapse for readahead, though...
> That is, failure to use readahead may be caused by memory pressure,
> scheduling delays, etc - how do you tell the difference between a
> process that would profit from readahead if the scheduler would let it
> and one that would not?
I don't think we'd need to know the difference at all times.
After all, TCP manages fine without knowing the reason for
packet loss ;)
> > IA64: a worthy successor to i860.
>
> Not the 432?
;)
Rik
-- IA64: a worthy successor to i860.http://www.surriel.com/ http://distro.conectiva.com/
Send all your spam to aardvark@nl.linux.org (spam digging piggy)
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Fri Aug 31 2001 - 21:00:21 EST