Re: swap-prefetch: A smart way to make good use of idle resources (was: updatedb)

["Indan Zupancic" <indan@nul.nu>]

On Fri, July 27, 2007 22:34, Arjan van de Ven wrote:
> On Fri, July 27, 2007 21:43, Al Boldi wrote:
>> IMHO, what everybody agrees on, is that swap-prefetch has a positive effect
>> in some cases, and nobody can prove an adverse effect (excluding power
>> consumption).  The reason for this positive effect is also crystal clear:
>> It prefetches from swap on idle into free memory, ie: it doesn't force
>
> the fact that there is free memory is ... strange. IN principle, Linux
> keeps almost no memory free (except some emergency buffers) so that
> things you swap in prematurely will BY DEFINITION go at the expense of
> other things that could be there....

It's not strange, the use case here is if something memory hungry process
is shut down it leaves behind a lot of free memory. Having things swapped
out while there's free memory is strange, so swap prefetch fills it up again.

> also, they take up seek time (5 to 10 msec), so if you were to read
> something else at the time you get additional latency.

If there's other disk activity swap prefetch shouldn't do much, so this isn't
really true.

>> Conclusion:  Either prove swap-prefetch is broken, or get this merged quick.

There are a whole lot of other requirements too than that it isn't broken (of
which most are fulfilled, but anyway). One reason could be that there's a
better solution out there for the problem swap prefetch tries to solve. That
said, as swap prefetch is here now for a while and that other solution not it's
not such a great argument.

Personally I think that a more generic solution would be better, one that
prefetches the lastly evicted pages back in, not favouring either of swap or
file data, like swap prefetch does now.

Greetings,

Indan


-
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/