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,
ST> On 13 Jul 1998 13:08:56 -0500, ebiederm+eric@npwt.net (Eric
ST> W. Biederman) said:

>>>>>>> "ST" == Stephen C Tweedie <sct@redhat.com> writes:
>> 1) We have a minimum size for the buffer cache in percent of physical pages.
>> Setting the minimum to 0% may help.

ST> ...

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

ST> Yep; I disabled those limits for the benchmarks I announced.  Disabling
ST> the ageing but keeping the limits in place still resulted in a
ST> performance loss.

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

ST> Yikes --- for large files the proposal that we do

>> do something like:
>> for(i = 0; i < inode->i_size; i+= PAGE_SIZE) {
>> page = find_in_page_cache(inode, i);
>> if (page) 
>> /* remove it */
>> ;
>> }

ST> will be disasterous.  No, I think we still need the per-inode page
ST> lists.  When we eventually get an fsync() which works through the page
ST> cache, this will become even more important.

Duh.  Ext2 only does with in truncate with the block cache on a real
truncate, when and inode is closed it doesn't need to do that.  Sorry
I though I had precedent for that algorithm.

O.k. scracth that idea.

So I guess a LRU list for pages will require that we increase the size
of struct page.  I guess it is makes sense if we can ultimately:
a) use if for every page on the system ala the swap cache.
b) remove the buffer cache which should provide the necessary
   expansion room.  So we won't ultimately use more space.
c) use it for a lru on dirty pages.
d) doesn't fragment memory with slabs...

I hate considering expanding struct page after all of the work
that has gone into shriking the lately....

And for writes it looks like I'll need a write time too, for best
performance.  I've written the code I just haven't tested it yet.

Zlatko could I talk you into setting the defines in mmap.h so it shmfs
will use those and report if bonnie improves...

Eric

p.s. Everyone please excuse any slow replies I'm in the middle of
moving and I can't read my mail too often.
--
This is a majordomo managed list.  To unsubscribe, send a message with
the body 'unsubscribe linux-mm me@address' to: majordomo@kvack.org