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

Zlatko Calusic
1998-07-18T13:28:24Z

ebiederm+eric@npwt.net (Eric W. Biederman) writes:

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

When it comes to benchmarking, I'm always prepared. :)

It's just, that I didn't understand completely what are you trying to
do, but if you have a prepared patch, I'll gladly test it.

BTW, looking at 2.1.109, I'm very pleased with the changes made in mm/
directory. Finally, free_memory_available is simple, readable and
efficient. ;)

Next week, I will test some ideas which possibly could improve things
WITH page aging.

I must admit, after lot of critics I made upon page aging, that I
believe it's the right way to go, but it should be done properly.
Performance should be better, not worse.

Regards,
--
Posted by Zlatko Calusic E-mail: <Zlatko.Calusic@CARNet.hr>
---------------------------------------------------------------------
Any sufficiently advanced bug is indistinguishable from a feature.