Re: swapping and the value of /proc/sys/vm/swappiness

[Marcelo Tosatti]

On Wed, Sep 08, 2004 at 09:20:08AM -0500, Ray Bryant wrote:
> 
> 
> 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.

On such huge memory machines I guess you have no choice but scale down the 
dirty limits for them to be "equivalent" with reference to IO device speed.

And as Martin says it depends on the workload also.

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

Huh, that changes the meaning of the dirty limits. Dont think its suitable
for mainline.

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

Now that must work - if its not we have a problem.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/