From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755730Ab0LMUyL (ORCPT ); Mon, 13 Dec 2010 15:54:11 -0500 Received: from mx2.netapp.com ([216.240.18.37]:3818 "EHLO mx2.netapp.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755316Ab0LMUyK convert rfc822-to-8bit (ORCPT ); Mon, 13 Dec 2010 15:54:10 -0500 X-IronPort-AV: E=Sophos;i="4.59,337,1288594800"; d="scan'208";a="494417531" Subject: Re: [PATCH 30/35] nfs: heuristics to avoid commit From: Trond Myklebust To: Wu Fengguang Cc: Andrew Morton , Jan Kara , Christoph Hellwig , Dave Chinner , "Theodore Ts'o" , Chris Mason , Peter Zijlstra , Mel Gorman , Rik van Riel , KOSAKI Motohiro , Greg Thelen , Minchan Kim , linux-mm , linux-fsdevel@vger.kernel.org, LKML In-Reply-To: <20101213150329.953837345@intel.com> References: <20101213144646.341970461@intel.com> <20101213150329.953837345@intel.com> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8BIT Organization: NetApp Inc Date: Mon, 13 Dec 2010 15:53:46 -0500 Message-ID: <1292273626.8795.19.camel@heimdal.trondhjem.org> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 (2.32.1-1.fc14) X-OriginalArrivalTime: 13 Dec 2010 20:53:47.0713 (UTC) FILETIME=[D6918B10:01CB9B07] Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, 2010-12-13 at 22:47 +0800, Wu Fengguang wrote: > plain text document attachment (writeback-nfs-should-commit.patch) > The heuristics introduced by commit 420e3646 ("NFS: Reduce the number of > unnecessary COMMIT calls") do not work well for large inodes being > actively written to. > > Refine the criterion to > - it has gone quiet (all data transfered to server) > - has accumulated >= 4MB data to commit (so it will be large IO) > - too few active commits (hence active IO) in the server Where does the number 4MB come from? If I'm writing a 4GB file, I certainly do not want to commit every 4MB; that would make for a total of 1000 commit requests in addition to the writes. On a 64-bit client +server both having loads of memory and connected by a decently a fast network, that can be a significant slowdown... Most of the time, we really want the server to be managing its dirty cache entirely independently of the client. The latter should only be sending the commit when it really needs to free up those pages. Cheers Trond -- Trond Myklebust Linux NFS client maintainer NetApp Trond.Myklebust@netapp.com www.netapp.com