mmap MAP_NOSYNC regression in 10.x

[Pieter de Goeje]

Konstantin Belousov schreef op 5-9-2014 10:06:
> On Fri, Sep 05, 2014 at 02:02:51AM -0500, Alan Cox wrote:
>> On Thu, Sep 4, 2014 at 7:29 PM, Pieter de Goeje <pieter at degoeje.nl> wrote:
>>
>>> After upgrading my month old 10-stable installation today (to r271093) ,
>>> I've noticed a that the kernel no longer honors the MAP_NOSYNC flag.
>>> Attached is a demonstration program that highlights the issue (also
>>> available here: http://pastebin.com/y0kvdn0r ).
>>>
>>> The program creates and mmap()s a 200MiB file and repeatedly writes zeros
>>> to it. The expected behavior is that under normal circumstances (no memory
>>> pressure), the dirtied pages are not flushed to disk. Observed is however
>>> that every ~30 seconds the syncer kicks in and basically halts the program
>>> while it does its job. The program prints a line everytime the throughput
>>> drops below 500MBps, well below memory bandwidth.
>>>
>>> mmap() is called like this:
>>>
>>>    void *p = mmap(NULL, len, PROT_READ | PROT_WRITE,
>>>       MAP_SHARED | MAP_NOSYNC | MAP_ALIGNED_SUPER, fd, 0);
>>>
>>> Sample output:
>>>
>>> write...
>>> zeroing: 209.6 MB
>>>   ...write: 5.839s
>>> mmap...
>>>   ...mmap: 0.000s
>>> 20.1s: memset #259: 34.7MBps - stalled
>>> 55.7s: memset #810: 34.7MBps - stalled
>>> 91.3s: memset #1359: 34.6MBps - stalled
>>> 100.0s: memset #1522: 3938.5MBps
>>> overall bandwidth: 3190.6MBps
>>> munmap...
>>>   ...munmap: 5.796s
>>> done
>>>
>>> (this is a rather old system)
>>>
>>> If necessary I'm willing to find out the exact commit that caused the
>>> problem.
>>>
>>>
>> That's not necessary.  This is a bug in the page fault handler's new fast
>> path.
> The following patch fixed the issue for me.

Thanks, works for me!

-
Pieter