Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756759Ab0BXLSb (ORCPT ); Wed, 24 Feb 2010 06:18:31 -0500 Received: from mail-gx0-f217.google.com ([209.85.217.217]:58535 "EHLO mail-gx0-f217.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1756671Ab0BXLS2 convert rfc822-to-8bit (ORCPT ); Wed, 24 Feb 2010 06:18:28 -0500 DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=rdtPmxzuPtNGdeu4aFkGtwdUz1QRIBuelbVCjf1NgkR1UXrd0U3AsSFZcy2bWp94J8 npshHenXIEmeB+qXJi55AkMwCBPp5SBW/Rc0O2r5b4cQer73J5eFxCgMpxYLpf0B6p4/ 0cwmeY/i/y1kOMFnEcmqPDz7IeOyH5TM3JETs= MIME-Version: 1.0 In-Reply-To: <20100224052215.GH16175@discord.disaster> References: <20100224024100.GA17048@localhost> <20100224032934.GF16175@discord.disaster> <20100224041822.GB27459@localhost> <20100224052215.GH16175@discord.disaster> Date: Wed, 24 Feb 2010 06:18:26 -0500 X-Google-Sender-Auth: 096ebceb1c6a0a26 Message-ID: Subject: Re: [RFC] nfs: use 2*rsize readahead size From: Akshat Aranya To: Dave Chinner Cc: Wu Fengguang , Trond Myklebust , "linux-nfs@vger.kernel.org" , "linux-fsdevel@vger.kernel.org" , Linux Memory Management List , LKML Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8BIT Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1485 Lines: 35 On Wed, Feb 24, 2010 at 12:22 AM, Dave Chinner wrote: > >> It sounds silly to have >> >> ? ? ? ? client_readahead_size > server_readahead_size > > I don't think it is ?- the client readahead has to take into account > the network latency as well as the server latency. e.g. a network > with a high bandwidth but high latency is going to need much more > client side readahead than a high bandwidth, low latency network to > get the same throughput. Hence it is not uncommon to see larger > readahead windows on network clients than for local disk access. > > Also, the NFS server may not even be able to detect sequential IO > patterns because of the combined access patterns from the clients, > and so the only effective readahead might be what the clients > issue.... > In my experiments, I have observed that the server-side readahead shuts off rather quickly even with a single client because the client readahead causes multiple pending read RPCs on the server which are then serviced in random order and the pattern observed by the underlying file system is non-sequential. In our file system, we had to override what the VFS thought was a random workload and continue to do readahead anyway. Cheers, Akshat -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/