Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 11 Oct 1996 10:34:20 +0100 (BST)
From:      Doug Rabson <dfr@render.com>
To:        Hidetoshi Shimokawa <simokawa@sat.t.u-tokyo.ac.jp>
Cc:        henrich@crh.cl.msu.edu, lite2@freebsd.org
Subject:   Re: Delayed write patch
Message-ID:  <Pine.BSF.3.95.961011103219.10204u-100000@minnow.render.com>
In-Reply-To: <9432.844966167@sat.t.u-tokyo.ac.jp>

next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, 11 Oct 1996, Hidetoshi Shimokawa wrote:

> Hi,
> 
> dfr> Thanks for the patch.  It improves performance for my SGI from ~720k/sec
> dfr> to ~870k/sec.  I modified the patch (and the nfs_dwrite patch) slightly
> I'm glad to hear this.
> Are you getting it under NFSv2 and 10BASE?
> 
> dfr> and added comments to try to explain what is happening.  Could you check
> dfr> the comments to make sure they agree with your understanding of the
> dfr> problem and I will commit this patch to current probably tomorrow.
> As you know, I'm not a native speaker of English, so I'm not sure that
> vfs.nfs.dwrite is a good notation. If you think vfs.nfs.delwri or
> another notation is better, I have no objection.

I think vfs.nfs.dwrite is fine.

> [...]
>
> "In this case, the lock is not taken because it is not necessary."
> 
> [...]
>
> "..., then just return without taking the lock. 
> It is necessary when a single iod 'captures' the recive lock.
> This situation often occurs while many 'delayed write buffers' are
> being processed"

I have included your new wording, thanks.

> 
> Actually, under delayed write process, single iod keeps recive lock,
> but other iods can process its reply without block.

I think I understand it a bit better now.

--
Doug Rabson, Microsoft RenderMorphics Ltd.	Mail:  dfr@render.com
						Phone: +44 171 734 3761
						FAX:   +44 171 734 6426





Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.3.95.961011103219.10204u-100000>