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

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

>>>>> "ZC" == Zlatko Calusic <Zlatko.Calusic@CARNet.hr> writes:

Let me just step back a second so I can be clear:

A) The idea proposed by Stephen way perhaps we could use Least
Recently Used lists instead of page aging.  It's effectively the same
thing but shrink_mmap can find the old pages much much faster, by
simply following a linked list.

B) This idea intrigues me because handling of generic dirty pages
I have about the same problem.  In cloneing bdflush for the page cache
I discovered two fields I would need to add to struct page to do an
exact cloning job.  A page writetime, and LRU list pointers for dirty
pages.  I went ahead and implemented them, but also implemented an
alternative, which is the default.

So on any discussion with LRU lists I'm terribly interested.
As soon as I get the time I'll even implement the more general case.
Mostly I just need to get my computer moved to where I am at so I can
code when I have free time :)

What I have now are controled by the defines I added to
include/linux/mm.h with my shmfs patches.
#undef USE_PG_FLUSHTIME  (This tells sync_old_pages when to stop)
#undef USE_PG_DIRTY_LIST (Define this for a first pass at an LRU list
for dirty pages)

If nothing else it's worth trying to see if it improves my write times
which fall way behind the read times, on Zlato's benchmark :(

If I can talk Zlatko or someone into looking at these it would be
nice.  I really need to get my own copy of bonnie and a few other
benchmarks...

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

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

Agreed.  We should look very carefully though to see if any aging
solution increases fragmentation.  According to Stephen the current
one does, and this may be a natural result of aging and not just a
single implementation :(

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