From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S264128AbTDJTZC (for ); Thu, 10 Apr 2003 15:25:02 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S264131AbTDJTZC (for ); Thu, 10 Apr 2003 15:25:02 -0400 Received: from neon-gw-l3.transmeta.com ([63.209.4.196]:32518 "EHLO neon-gw.transmeta.com") by vger.kernel.org with ESMTP id S264128AbTDJTZA (for ); Thu, 10 Apr 2003 15:25:00 -0400 To: linux-kernel@vger.kernel.org From: "H. Peter Anvin" Subject: Re: msync() more expensive than fsync()? Date: 10 Apr 2003 12:36:16 -0700 Organization: Transmeta Corporation, Santa Clara CA Message-ID: References: <3E92FAE6.8000300@nortelnetworks.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7BIT Disclaimer: Not speaking for Transmeta in any way, shape, or form. Copyright: Copyright 2003 H. Peter Anvin - All Rights Reserved Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Followup to: <3E92FAE6.8000300@nortelnetworks.com> By author: Chris Friesen In newsgroup: linux.dev.kernel > > Without any explicit flushing it takes 8 usec to log a message. > > If I msync() only the pages that were touched in writing (usually 3 pages) it > takes 39 usecs to log a message. > > If I fsync() the entire file (200KB) it takes 12 usec to log a message. > > Why the additional cost for msync()? I would have thought it would be faster > since it is explicitely for mmapped memory areas. As a side note, the > difference is even more extreme if a file is used on a disk-backed filesystem. > Because fsync() does less work. In particular, fsync() doesn't do the work you want: unlike msync() it doesn't guarantee that memory maps are consistent with the filesystem. -hpa -- at work, in private! "Unix gives you enough rope to shoot yourself in the foot." Architectures needed: ia64 m68k mips64 ppc ppc64 s390 s390x sh v850 x86-64