[dm-devel] [Lsf-pc] [LSF/MM TOPIC] a few storage topics

[Loke, Chetan]

> So there are two separate problems mentioned here.  The first is to
> ensure that readahead (RA) pages are treated as more disposable than
> accessed pages under memory pressure and then to derive a statistic for
> futile RA (those pages that were read in but never accessed).
> 
> The first sounds really like its an LRU thing rather than adding yet
> another page flag.  We need a position in the LRU list for never
> accessed ... that way they're first to be evicted as memory pressure
> rises.
> 
> The second is you can derive this futile readahead statistic from the
> LRU position of unaccessed pages ... you could keep this globally.
> 
> Now the problem: if you trash all unaccessed RA pages first, you end up
> with the situation of say playing a movie under moderate memory
> pressure that we do RA, then trash the RA page then have to re-read to display
> to the user resulting in an undesirable uptick in read I/O.
> 
> Based on the above, it sounds like a better heuristic would be to evict
> accessed clean pages at the top of the LRU list before unaccessed clean
> pages because the expectation is that the unaccessed clean pages will
> be accessed (that's after all, why we did the readahead).  As RA pages age

Well, the movie example is one case where evicting unaccessed page may not be the right thing to do. But what about a workload that perform a random one-shot search?
The search was done and the RA'd blocks are of no use anymore. So it seems one solution would hurt another.

We can try to bring-in process run-time heuristics while evicting pages. So in the one-shot search case, the application did it's thing and went to sleep.
While the movie-app has a pretty good run-time and is still running. So be a little gentle(?) on such apps? Selective eviction?

In addition what if we do something like this:

RA block[X], RA block[X+1], ... , RA block[X+m]

Assume a block reads 'N' pages.

Evict unaccessed RA page 'a' from block[X+2] and not [X+1].

We might need tracking at the RA-block level. This way if a movie touched RA-page 'a' from block[X], it would at least have [X+1] in cache. And while [X+1] is being read, the new slow-down version of RA will not RA that many blocks.

Also, application's should use xxx_fadvise calls to give us hints...


> James

Chetan Loke