mmap() question

[Dmitry Sivachenko]

On 12.10.2013, at 13:59, Konstantin Belousov <kostikbel at gmail.com> wrote:
> 
> I was not able to reproduce the situation locally. I even tried to start
> a lot of threads accessing the mapped regions, to try to outrun the
> pagedaemon. The user threads sleep on the disk read, while pagedaemon
> has a lot of time to rebalance the queues. It might be a case when SSD
> indeed makes a difference.
> 


With ordinary SATA drive it will take hours just to read 20GB of data from disk because of random access, it will do a lot of seeks and reading speed will be extremely low.

SSD dramatically improves reading speed.


> Still, I see how this situation could appear. The code, which triggers
> OOM, never fires if there is a free space in the swapfile, so the
> absense of swap is neccessary condition to trigger the bug.  Next, OOM
> calculation does not account for a possibility that almost all pages on
> the queues can be reused. It just fires if free pages depleted too much
> or free target cannot be reached.


First I tried with some swap space configured.  The OS started to swap out my process after it reached about 20GB which is also not what I expected:  what is the reason to swap out regions of read-only mmap()ed files?  Is it the expected behaviour?


> 
> Below is the prototype patch, against HEAD.  It is not applicable to
> stable, please use HEAD kernel for test.


Thanks, I will test the patch soon and report the results.