Page cache ageing: yae or nae?

Page cache ageing: yae or nae?

[Stephen C. Tweedie]

Hi Rik,

In following the latest round of performance reports from Zlatzo
Calusic, it's clear we still need to think a bit about the
aggressiveness of the page cache.  It's not a maximum age issue: _any_
scheme which fails to clear a page from the page cache in one round of
ageing will suffer from his problem with large copies.

Could you let me know just what benchmarks you were running when you
added the first page ageing code to see a speedup?  I think we need to
look carefully at the properties of the ageing scheme and the simple
clock algorithm we had before to see where the best compromise is.  It
may be that we can get away with something simple like just reducing
the initial page age for the page cache, but I'd like to make sure
that the readahead problems you alluded to are not brought back by any
other changes we make to the mechanism.

--Stephen
--
This is a majordomo managed list.  To unsubscribe, send a message with
the body 'unsubscribe linux-mm me@address' to: majordomo@kvack.org

Re: Page cache ageing: yae or nae?

[Rik van Riel]

On Mon, 27 Jul 1998, Stephen C. Tweedie wrote:

> Could you let me know just what benchmarks you were running when you
> added the first page ageing code to see a speedup?  I think we need to

It's not really a benchmark; it's just that mp3s or
quicktimes (played from disk instead of ram) run
smoothly with page aging and skip without.

> look carefully at the properties of the ageing scheme and the simple
> clock algorithm we had before to see where the best compromise is.  It

The clock algorithm will throw out the not-yet-used page we
just read-ahead (and which will be needed immediately after
clearing -- cf. Murphy).

An aging (or better, LRU) algorithm will only throw out the
read-ahead page if:
- we don't use it in a larger time
- we have used it and don't use it any more

One of the ideas behind this is that swap I/O is clustered
and often cheaper than filesystem I/O (both are the case on
my system, which is tuned for this).

On systems with a single spindle and the swap partition
_far_ away, both assumptions will obviously break.

Since both types of systems can be found rather often, a
dynamic scheme would probably be best; maybe even a 'cost'
factor on mounting/swapon...

> may be that we can get away with something simple like just reducing
> the initial page age for the page cache, but I'd like to make sure
> that the readahead problems you alluded to are not brought back by any
> other changes we make to the mechanism.

The problem is with balancing, not with balancing memory usage,
but with balancing I/O cost.

I think we should think up a mechanism that both preserves the
readahead performance and balances I/O; memory balancing is a
tertiary issue here...

Rik.
+-------------------------------------------------------------------+
| Linux memory management tour guide.        H.H.vanRiel@phys.uu.nl |
| Scouting Vries cubscout leader.      http://www.phys.uu.nl/~riel/ |
+-------------------------------------------------------------------+

--
This is a majordomo managed list.  To unsubscribe, send a message with
the body 'unsubscribe linux-mm me@address' to: majordomo@kvack.org

Re: Page cache ageing: yae or nae?

[Stephen C. Tweedie]

Hi,

On Tue, 28 Jul 1998 18:13:11 +0200 (CEST), Rik van Riel
<H.H.vanRiel@phys.uu.nl> said:

> On Mon, 27 Jul 1998, Stephen C. Tweedie wrote:
>> Could you let me know just what benchmarks you were running when you
>> added the first page ageing code to see a speedup?  I think we need to

> It's not really a benchmark; it's just that mp3s or
> quicktimes (played from disk instead of ram) run
> smoothly with page aging and skip without.

Right, but we don't need page aging to address that.  Currently we don't
set the page referenced bit on a readahead IO; setting that bit will be
sufficient to guard the page for at least one full pass of the
shrink_mmap scan.

Can you try the patch below (to 112-pre2) and see if it allows smooth
playback?  It disables page aging and restores the original shrink_mmap
loop limits, but adds the one-pass readahead protection.

--Stephen

----------------------------------------------------------------
--- mm/filemap.c.~1~	Wed Jul 29 11:50:58 1998
+++ mm/filemap.c	Wed Jul 29 12:01:31 1998
@@ -172,11 +172,13 @@
 				break;
 			}
 			age_page(page);
+#if 0
 			if (page->age)
 				break;
 
 			if (page_cache_size * 100 < (page_cache.min_percent * num_physpages))
 				break;
+#endif
 			if (PageSwapCache(page)) {
 				delete_from_swap_cache(page);
 				return 1;
@@ -212,8 +214,8 @@
 	struct page * page;
 	int count_max, count_min;
 
-	count_max = (limit<<2) >> (priority>>1);
-	count_min = (limit<<2) >> (priority);
+	count_max = (limit<<1) >> (priority>>1);
+	count_min = (limit<<1) >> (priority);
 
 	page = mem_map + clock;
 	do {
@@ -322,6 +324,7 @@
 			 */
 			page = mem_map + MAP_NR(page_cache);
 			add_to_page_cache(page, inode, offset, hash);
+			set_bit(PG_referenced, &page->flags);
 			inode->i_op->readpage(file, page);
 			page_cache = 0;
 		}
--
This is a majordomo managed list.  To unsubscribe, send a message with
the body 'unsubscribe linux-mm me@address' to: majordomo@kvack.org

Re: Page cache ageing: yae or nae?

[Rik van Riel]

On Wed, 29 Jul 1998, Stephen C. Tweedie wrote:

> Right, but we don't need page aging to address that.  Currently we don't
> set the page referenced bit on a readahead IO; setting that bit will be
> sufficient to guard the page for at least one full pass of the
> shrink_mmap scan.

Hmm, one full pass of shrink_mmap will probably take quite a
number of calls to that function, since without aging we are
able to find far more freeable pages...

At the moment I'm super-busy with my (vacation) job, but I
might be able to find some time this weekend. Maybe some
folks on linux-mm have spare time?

Rik.
+-------------------------------------------------------------------+
| Linux memory management tour guide.        H.H.vanRiel@phys.uu.nl |
| Scouting Vries cubscout leader.      http://www.phys.uu.nl/~riel/ |
+-------------------------------------------------------------------+


--
This is a majordomo managed list.  To unsubscribe, send a message with
the body 'unsubscribe linux-mm me@address' to: majordomo@kvack.org