Re: Linux-2.1.129..

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

>>>>> "RR" == Rik van Riel <H.H.vanRiel@phys.uu.nl> writes:

RR> On 23 Nov 1998, Eric W. Biederman wrote:
>> The simplest model (and what we use for disk writes) is after
>> something becomes dirty to wait a little bit (in case of more
>> writes, (so we don't flood the disk)) and write the data to disk. 

RR> This waiting is also a good thing if we want to do proper
RR> I/O clustering. I believe DU has a switch to only write
RR> dirty data when there's more than XX kB of contiguous data
RR> at that place on the disk (or the data is old).

I can tell who has been reading Digital Unix literature latetly.

>> Ideally/Theoretically I think that is what we should be doing for
>> swap as well, as it would spread out the swap writes across evenly
>> across time.  And should leave most of our pages clean. 

RR> Something like this is easily accomplished by pushing the
RR> non-accessed pages into swap cache and swap simultaneously,
RR> remapping the page from swap cache when we want to access
RR> it again.

RR> In order to spread out the disk I/O evenly (why would we
RR> want to do this?

Imagine a machine with 1 Gigabyte of RAM and 8 Gigabyte of swap,
in heavy use.  Swapping but not thrashing.

You can't swap out several hundred megabytes all at once.
They need to be swapped out over time.   For pages that are not likely to change
you want them to hit the disk soon after they get set, so you have
more clean memory,  and don't need to write all of the data out when
you get busy.  

You can handle a suddne flurry of network traffic much better this way
for example.


>> The correct ratio (of pages to free from each source) (compuated
>> dynamically) would be:  (# of process pages)/(# of pages) 
>> 
>> Basically for every page kswapd frees shrink_mmap must also free one
>> page.  Plus however many pages shrink_mmap used to return. 

RR> This is clearly wrong.  

No. If for each page we schedule to be swapped, we reclaim a different
page with shrink_mmap immediately.... so we have free ram.

That should keep the balance between swapping and mm as it has
always been.  But I doubt we need to go even that far, to get a working balance.


As far as fixed percentages.  It's a loose every time, and I
won't drop a working feature for an older lesser design.   Having tuneable
fixed percentages is only a win on a 1 application, 1 load pattern box.


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