From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx2.netapp.com ([216.240.18.37]:58531 "EHLO mx2.netapp.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1756020Ab0AFSwz convert rfc822-to-8bit (ORCPT ); Wed, 6 Jan 2010 13:52:55 -0500 Subject: Re: [PATCH] improve the performance of large sequential write NFS workloads From: Trond Myklebust To: Peter Zijlstra Cc: Wu Fengguang , Jan Kara , Steve Rago , "linux-nfs@vger.kernel.org" , "linux-kernel@vger.kernel.org" , "jens.axboe" , Peter Staubach , Arjan van de Ven , Ingo Molnar , "linux-fsdevel@vger.kernel.org" In-Reply-To: <1262803040.4049.62.camel@laptop> References: <20091222015907.GA6223@localhost> <1261578107.2606.11.camel@localhost> <20091223180551.GD3159@quack.suse.cz> <1261595574.6775.2.camel@localhost> <20091224025228.GA12477@localhost> <1261656281.3596.1.camel@localhost> <20091225055617.GA8595@localhost> <1262190168.7332.6.camel@localhost> <20091231050441.GB19627@localhost> <1262286828.8151.113.camel@localhost> <20100106030346.GA15962@localhost> <1262796962.4251.91.camel@localhost> <1262802387.4251.117.camel@localhost> <1262803040.4049.62.camel@laptop> Content-Type: text/plain; charset="UTF-8" Date: Wed, 06 Jan 2010 13:52:07 -0500 Message-ID: <1262803927.4251.133.camel@localhost> Sender: linux-nfs-owner@vger.kernel.org List-ID: MIME-Version: 1.0 On Wed, 2010-01-06 at 19:37 +0100, Peter Zijlstra wrote: > On Wed, 2010-01-06 at 13:26 -0500, Trond Myklebust wrote: > > OK. It looks as if the only key to finding out how many unstable writes > > we have is to use global_page_state(NR_UNSTABLE_NFS), so we can't > > specifically target our own backing-dev. > > Would be a simple matter of splitting BDI_UNSTABLE out from > BDI_RECLAIMABLE, no? > > Something like OK. How about if we also add in a bdi->capabilities flag to tell that we might have BDI_UNSTABLE? That would allow us to avoid the potentially expensive extra calls to bdi_stat() and bdi_stat_sum() for the non-nfs case? Cheers Trond From mboxrd@z Thu Jan 1 00:00:00 1970 From: Trond Myklebust Subject: Re: [PATCH] improve the performance of large sequential write NFS workloads Date: Wed, 06 Jan 2010 13:52:07 -0500 Message-ID: <1262803927.4251.133.camel@localhost> References: <20091222015907.GA6223@localhost> <1261578107.2606.11.camel@localhost> <20091223180551.GD3159@quack.suse.cz> <1261595574.6775.2.camel@localhost> <20091224025228.GA12477@localhost> <1261656281.3596.1.camel@localhost> <20091225055617.GA8595@localhost> <1262190168.7332.6.camel@localhost> <20091231050441.GB19627@localhost> <1262286828.8151.113.camel@localhost> <20100106030346.GA15962@localhost> <1262796962.4251.91.camel@localhost> <1262802387.4251.117.camel@localhost> <1262803040.4049.62.camel@laptop> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8BIT Cc: Wu Fengguang , Jan Kara , Steve Rago , "linux-nfs-u79uwXL29TY76Z2rM5mHXA@public.gmane.org" , "linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org" , "jens.axboe" , Peter Staubach , Arjan van de Ven , Ingo Molnar , "linux-fsdevel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org" To: Peter Zijlstra Return-path: In-Reply-To: <1262803040.4049.62.camel@laptop> Sender: linux-nfs-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org List-Id: linux-fsdevel.vger.kernel.org On Wed, 2010-01-06 at 19:37 +0100, Peter Zijlstra wrote: > On Wed, 2010-01-06 at 13:26 -0500, Trond Myklebust wrote: > > OK. It looks as if the only key to finding out how many unstable writes > > we have is to use global_page_state(NR_UNSTABLE_NFS), so we can't > > specifically target our own backing-dev. > > Would be a simple matter of splitting BDI_UNSTABLE out from > BDI_RECLAIMABLE, no? > > Something like OK. How about if we also add in a bdi->capabilities flag to tell that we might have BDI_UNSTABLE? That would allow us to avoid the potentially expensive extra calls to bdi_stat() and bdi_stat_sum() for the non-nfs case? Cheers Trond -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html