Date: Fri, 05 Sep 2014 13:56:40 +0200 From: Pieter de Goeje <pieter@degoeje.nl> To: Konstantin Belousov <kostikbel@gmail.com> Cc: alc@freebsd.org, hackers@freebsd.org Subject: Re: mmap MAP_NOSYNC regression in 10.x Message-ID: <5409A4F8.6020204@degoeje.nl> In-Reply-To: <20140905080633.GM2737@kib.kiev.ua> References: <540903FF.6010602@degoeje.nl> <CAJUyCcNiLwLuL9crpQBjSdg4ED5kR53fPjyJG3HNmP5Roor8RQ@mail.gmail.com> <20140905080633.GM2737@kib.kiev.ua>
next in thread | previous in thread | raw e-mail | index | archive | help
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@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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?5409A4F8.6020204>