From: trond.myklebust@fys.uio.no
Subject: RE: [PATCH 2.6.3] Add write throttling to NFS client
Date: Mon, 1 Mar 2004 18:38:47 +0100 (CET)
Sender: nfs-admin@lists.sourceforge.net
Message-ID: <34574.207.214.87.84.1078162727.squirrel@webmail.uio.no>
References: <20040301081456.37082.qmail@web12823.mail.yahoo.com>
Mime-Version: 1.0
Content-Type: text/plain;charset=iso-8859-1
Cc: "Bogdan Costescu" <bogdan.costescu@iwr.uni-heidelberg.de>,
     "Charles Lever" <Charles.Lever@netapp.com>,
     "Olaf Kirch" <okir@suse.de>,"Greg Banks" <gnb@melbourne.sgi.com>,
     nfs@lists.sourceforge.net,Shantanu.Goel@lehman.com
To: "Shantanu Goel" <sgoel01@yahoo.com>
In-Reply-To: <20040301081456.37082.qmail@web12823.mail.yahoo.com>
Errors-To: nfs-admin@lists.sourceforge.net

P? m? , 01/03/2004 klokka 00:14, skreiv Shantanu Goel:
> I did not make that assumption.  It does not appear to
> be a problem in practice.   I ran 4 dd's each writing
> 256MB in parallel on a machine with 2 CPUs and 64MB
> memory and it chugged along fine and still allowed
> other NFS activity on the same mount point. However, I
> believe this reflects the  way the NFS layer is
> implemented  (most request ARE submitted by the writing
> process except in the case of less than a page worth
> of writes).  However, if that were to ever change,
> your argument will probably be valid.

Sigh... See the patch linux-2.6.3-02-strategy.dif on the usual patch site.
People are asking that we cache more than is currently done in order to
allow for better random write performance.

> > Yes, or alternatively, just give the tasks a numeric
> > priority. That's all
> > we do for real tasks after all...
> >
>
> Just assigning a priority to requests will not fix the
> issue.  The whole reason I started looking at this was
> heavy writing to a single inode blocks out all other
> async write activity.  To give a concrete example.
> Start a dd in the background and then start Mozilla.
> Even if you give priority to sync requests, Mozilla
> will hang when it writes its cache files because to
> the RPC layer, one async write will look the same as
> the next.  The RPC layer must segregate tasks based on
> some criteria.  I chose to use the process id which
> seems to work pretty well in practice with the current
> implementation of NFS.  So I see no way around
> batching tasks based on either a cookie or process id.

Huh? Just have the asynchronous tasks sit in a different priority bucket
to the synchronous ones and schedule, say 4 asynchronous tasks for every 1
synchronous one. Why would this be so difficult?

Cheers,
  Trond


-------------------------------------------------------
SF.Net is sponsored by: Speed Start Your Linux Apps Now.
Build and deploy apps & Web services for Linux with
a free DVD software kit from IBM. Click Now!
http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click
_______________________________________________
NFS maillist  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs