From owner-freebsd-hackers@FreeBSD.ORG Fri Sep 5 12:13:03 2014 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 689F2F8; Fri, 5 Sep 2014 12:13:03 +0000 (UTC) Received: from out142-ams.mf.surf.net (out142-ams.mf.surf.net [145.0.1.142]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id EBB751C8D; Fri, 5 Sep 2014 12:13:01 +0000 (UTC) Received: from out64-ams.mf.surf.net (out64-ams.mf.surf.net [145.0.1.64]) by fbout1-ams.mf.surf.net (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id s85BuxFb028533; Fri, 5 Sep 2014 13:56:59 +0200 Received: from smtps.utwente.nl (smtp-o2.utsp.utwente.nl [130.89.2.10]) by outgoing3-ams.mf.surf.net (8.14.4/8.14.4/Debian-4) with ESMTP id s85Bxxa5017491; Fri, 5 Sep 2014 13:59:59 +0200 Received: from [130.89.165.91] (nox.student.utwente.nl [130.89.165.91]) by smtps.utwente.nl (8.13.8) with ESMTP id s85BumbW022146; Fri, 5 Sep 2014 13:56:50 +0200 Message-ID: <5409A4F8.6020204@degoeje.nl> Date: Fri, 05 Sep 2014 13:56:40 +0200 From: Pieter de Goeje User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Konstantin Belousov Subject: Re: mmap MAP_NOSYNC regression in 10.x References: <540903FF.6010602@degoeje.nl> <20140905080633.GM2737@kib.kiev.ua> In-Reply-To: <20140905080633.GM2737@kib.kiev.ua> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Bayes-Prob: 0.0001 (Score 0, tokens from: utwente-out:default, base:default, @@RPTN) X-Spam-Score: -0.50 () [Tag at 5.00] 2450(0),CC(NL:-0.5) X-CanIt-Geo: ip=130.89.2.10; country=NL; region=Provincie Overijssel; city=Enschede; latitude=52.2195; longitude=6.8912; http://maps.google.com/maps?q=52.2195,6.8912&z=6 X-CanItPRO-Stream: utwente-out:default (inherits from utwente:default, base:default) X-Canit-Stats-ID: 0bMLnXX7A - f2747e0abf2a - 20140905 (trained as not-spam) X-Scanned-By: CanIt (www . roaringpenguin . com) Cc: alc@freebsd.org, hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Sep 2014 12:13:03 -0000 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 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