Ed Tomlinson wrote:

Hi Andrew

Here is slablru for 32-mm1.  This is based on a version ported to 31ish-mm1.  It should be
stable.  Its been booted as UP (32-mm1) and SMP on UP  (31ish-mm1 only) and works as expected.

Cool.  But the diff adds tons of stuff which is already added by -mm1.
I suspect you diffed against 2.5.31 base?

A typical test cycle involved:
find / -name "*" > /dev/null
edit a large tif with the gimp
run dbench a few times with the dbench dir on tmpfs (trying to use gimp too)
run dbench a few times from a reiserfs dir (trying to use gimp too)
use the box for news/mail, atp-get update/upgrade etc, wait a few hours and repeat

31ish-mm1 survived a day of this, 32-mm1 is sending this message after one cycle.

Andrew, what do you thing about adding slablru to your experimental dir?

No probs.
 

There is also a version for virgin 2.5.32, anyone wanting it should email me - one big
patch is eats enough bandwidth.

One interesting change in this version.  We only add the first page of a slab to the lru.  The
reference bit setting logic for slabs has been modified to set the bit on the first page.
Pagevec created a little bit of a problem for slablru.  How do we know the order of the
slab page when its being freed?   My solution is to use 3 bits in page->flags and save the
order there.  Then free_pages_ok was modified to take the order from page->flags.  This
was implement in a minimal fashion.  Think Wli is working on a more elaborate version of
this - fleshed out, it could be used to support large pages in the vm.

hm.  What happened to the idea of walking mem_map[], looking for continuation
pages? (This would need to be done via pfn_to_page(), I guess).
 

Second topic.

I have also included an optimisation for vmscan.  I found that the current code would reduce
the inactive list to almost nothing when applications create large numbers of active pages very
quickly run (ie. gimp loading and editing large 20m+ tiffs).  This reduces the problem.   Always
allowing nr_pages to be scanned caused the active list to be reduced to almost nothing when
something like gimp exited and we had another task adding lots to the inactive list.  This
is fixed here too.  I do wonder if zone->refill_counter, as implemented, is a great idea.  Do
we really need/want to remember to scan the active list if it has massively decreased in size
because some app exited?  Maybe some sort of decay logic should be used...

Well the refill counter thingy is just an optimisation: rather than calling refill_inacative()
lots of times to just grab two or three pages, we wait until it builds up to 32, and then
go deactivate 32 pages.

But ugh, it's a bit broken.  Yup, you're right.  Need to s/if/while/ in shrink_zone().

But we do need to slowly sift through the active list even when the inactive
list is enormously bigger.  Otherwise, completely dead pages will remain in-core
forever if there's a lot of pagecache activity going on.
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/