Re: why swap at all?

[Nick Piggin <nickpiggin@yahoo.com.au>]

Buddy Lumpkin wrote:
>>>3) once physical memory is full, file system I/O will only benefit from
>>>reads that incur a minor fault. All other file system operations 
>>>are bound
>>>by the rate you can reclaim pages from physical memory.
>>>
> 
> 
>>No, typically we can reclaim memory very quickly and the operations
>>are bound by the speed of the block device.
> 
> 
> So if all physical memory is full with either pagecache or anonymous memory,
> where are you going to put these operations that are bound by the speed of
> the block device?
> 
> You have to evict pages at the same rate your reading them in or writing to
> the filesystem else you have nowhere to put them. This means that the rate
> you can access the filesystem is governed by the rate you can evict pages
> from memory.
> 

... and the speed of the block device. The minimum of the two actually.
Usually we can reclaim memory *much* faster than the block device can
fill it. Didn't you read what I had said?

> Couple that with the fact that there are many pte's pointing at the same
> physical page (shared page) in many cases where many processes are running
> on the system. Because all of the references to that page must be removed
> before the page can be evicted, there are some absolute limitations in the
> rate that pages can be evicted from memory as the number of processes
> running on the system and the total amount of memory increases.
> 

This is still many orders of magnitude faster than filling the page
from disk, and you typically don't reclaim much of mapped memory anyway.

We are sort of spamming lkml now so let's get this finished up.

If you want to talk about memory management basics, there should
be some more helpful lists.