On Thursday 28 June 2001 14:20, mike_phillips@urscorp.com wrote:
> > If individual pages could be classified as code (text segments),
> > data, file cache, and so on, I would specify costs to the paging
> > of such pages in or out. This way I can make the system perfer
> > to drop a file cache page that has not been accessed for five
> > minutes, over a program text page that has not been acccessed
> > for one hour (or much more).
>
> This would be extremely useful. My laptop has 256mb of ram, but every day
> it runs the updatedb for locate. This fills the memory with the file
> cache. Interactivity is then terrible, and swap is unnecessarily used. On
> the laptop all this hard drive thrashing is bad news for battery life
> (plus the fact that laptop hard drives are not the fastest around). I
> purposely do not run more applications than can comfortably fit in the
> 256mb of memory.
>
> If fact, to get interactivity back, I've got a small 10 liner that mallocs
> memory to *force* stuff into swap purely so I can have a large block of
> memory back for interactivity.
>
> Something simple that did "you haven't used this file for 30mins, flush it
> out of the cache would be sufficient"
Updatedb fills memory full of clean file pages so there's nothing to flush.
Did you mean "evict"?
Roughly speaking we treat clean pages as "instantly relaimable". Eviction
and reclaiming are done in the same step (look at reclaim_page). The key to
efficient mm is nothing more or less than choosing the best victim for
reclaiming and we aren't doing a spectacularly good job of that right now.
There is a simple change in strategy that will fix up the updatedb case quite
nicely, it goes something like this: a single access to a page (e.g., reading
it) isn't enough to bring it to the front of the LRU queue, but accessing it
twice or more is. This is being looked at.
Note that we don't actually use a LRU queue, we use a more efficient
approximation called aging, so the above is not a recipe for implementation.
-- Daniel - 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 : Sat Jun 30 2001 - 21:00:19 EST