Marcelo Tosatti wrote:

> 
> Andrew, dirty_ratio and dirty_background_ratio (as low as 5% each) did not significantly 
> affect the amount of swapped out data, only a small effect on _how soon_ anonymous 
> memory was swapped out.
> 

I looked at the get_dirty_limits() code and for the test cases I was running,
we have mapped > 90% of memory.  So what will happen is that dirty_ratio will 
be thresholded at 5%, and background_ratio will be 1%.  Changing values in 
/proc won't modify this at all (well, you could force background_ratio to 0%.)

It seems to me that the 5% number in there is more or less arbitrary.  If we 
are on a big memory Altix (4 TB), 5% of memory would be 200 GB. That is a lot 
of page cache.

It seems get_dirty_limits() would be a lot simpler (and automatically scale as 
memory is mapped) if the limits were interpreted as being in terms of the 
amount of unmapped memory.  A patch that implements this idea is attached.
(Andrew -- if it comes to that I can submit this patch inline -- this is just 
for talking at the moment).

I'll run a few of the tests with this modified kernel and see if they are any 
different.

> And finally, Ray, the difference you see between 2.6.6 and 2.6.7 can be explained, 
> as noted by others in this thread, to vmscan.c changes (page replacement/scanning policy
> changes were made).

Yep.  I can probably live with those minor differences though.  I would be 
happier if the system didn't swap anything at all for low values of 
swappiness, though.

> 
> Will continue with more tests tomorrow.
> 

-- 
Best Regards,
Ray
-----------------------------------------------
                   Ray Bryant
512-453-9679 (work)         512-507-7807 (cell)
raybry@sgi.com             raybry@austin.rr.com
The box said: "Requires Windows 98 or better",
            so I installed Linux.
-----------------------------------------------