From owner-freebsd-stable@FreeBSD.ORG Wed Jul 2 12:00:03 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3B3481065670 for ; Wed, 2 Jul 2008 12:00:03 +0000 (UTC) (envelope-from marcus@blazingdot.com) Received: from marklar.blazingdot.com (marklar.blazingdot.com [207.154.84.83]) by mx1.freebsd.org (Postfix) with SMTP id 01A798FC19 for ; Wed, 2 Jul 2008 12:00:02 +0000 (UTC) (envelope-from marcus@blazingdot.com) Received: (qmail 5696 invoked by uid 503); 2 Jul 2008 12:00:02 -0000 Date: Wed, 2 Jul 2008 05:00:02 -0700 From: Marcus Reid To: freebsd-stable@freebsd.org Message-ID: <20080702120002.GB65355@blazingdot.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Coffee-Level: nearly-fatal User-Agent: Mutt/1.5.6i Subject: msync() differences between Linux and FreeBSD X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Jul 2008 12:00:03 -0000 Hi, I recently had a patch accepted to the ports collection that took out an msync() call that seriously detrimented performance for rrdtool updates. It seems that in FreeBSD, msync() waits for bits to be committed to disk even when MS_ASYNC is specified. Under Linux, there is not such a wait for msync(). First off, I don't know how frequently msync() is used, and whether changing its behavior would impact the performance of many things. It's possible that FreeBSD msync() behavior is more correct in some ways. From a message from Matt Dillon on this same list: It used to be that msync() only synced VM pages to the underlying file, making them consistent with read()'s and write()'s against the underlying file. Since FreeBSD uses a unified VM page cache this is always true. However, the Open Group specification now requires that the dirty pages actually be written out to the underlying media... i.e. issue real I/O. So msync() can't be a NOP if you go by the OpenGroup specification. Is there a spec that FreeBSD is adhering to that prevents msync() with MS_ASYNC from being a NOP, seeing as munmap() does the job? And does this really matter for the real-world performance of some apps? Thanks, Marcus