Re: More info: 2.1.108 page cache performance on low memory

[ebiederm+eric@npwt.net (Eric W. Biederman)]

>>>>> "ST" == Stephen C Tweedie <sct@redhat.com> writes:

ST> Hi all,
ST> OK, a bit more benchmarking is showing bad problems with page ageing.
ST> I've been running 2.1 with a big ramdisk and without, with page ageing
ST> and without.  The results for a simple compile job (make a few
ST> dependency files then compile four .c files) look like this:

ST> 	2.0.34, 6m ram:			1:22

ST> 	2.1.108, 16m ram, 10m ramdisk:
ST> 		With page cache ageing:	Not usable (swap death during boot.)
ST> 		Without cache ageing:	8:47

ST> 	2.1.108, 6m ram:
ST> 		With page cache ageing:	4:14
ST> 		Without cache ageing:	3:22

O.k. Just a few thoughts.
1) We have a minimum size for the buffer cache in percent of physical pages.
   Setting the minimum to 0% may help.

2) If we play with LRU list it may be most practical use page->next and page->prev
   fields for the list, and for truncate_inode_pages && invalidate_inode_pages
do something like:
for(i = 0; i < inode->i_size; i+= PAGE_SIZE) {
	page = find_in_page_cache(inode, i);
	if (page) 
		/* remove it */
		;
}
And remove the inode->i_pages list.  This should be roughly equivalent
to the bforgets needed by truncate anyway so should impose not large
peformance penalty.

Personally I think it is broken to set the limits of cache sizes
(buffer & page) to anthing besides: max=100% min=0% by default.

But now that we have this hand tuneing option in addition to auto
tuning we should experiment with it as well.

Eric

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