On Sat, Oct 12, 2013 at 04:04:31PM +0400, Dmitry Sivachenko wrote: > > On 12.10.2013, at 13:59, Konstantin Belousov <kostik...@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? > How did you concluded that the pages from your r/o mappings were paged out ? VM never does this. Only anonymous memory could be written to swap file, including the shadow pages for the writeable COW mappings. I suspect that you have another 20GB of something used on the machine meantime.
> > > > > 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.
pgp4mxTG6rGdf.pgp
Description: PGP signature