Date: Fri, 11 Oct 1996 01:49:27 +0900 From: Hidetoshi Shimokawa <simokawa@sat.t.u-tokyo.ac.jp> To: Doug Rabson <dfr@render.com> Cc: henrich@crh.cl.msu.edu, lite2@freebsd.org Subject: Re: Delayed write patch Message-ID: <9432.844966167@sat.t.u-tokyo.ac.jp>
next in thread | raw e-mail | index | archive | help
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. dfr> + * If nfs_rcvlock() returns EALREADY, that means that dfr> + * the reply has already been recieved by another dfr> + * process and we can return immediately. In this dfr> + * case, the lock is not taken to avoid races with dfr> + * other processes. "In this case, the lock is not taken because it is not necessary." dfr> + /* dfr> + * If our reply was recieved while we were sleeping, dfr> + * then just return without taking the lock to avoid a dfr> + * situation where a single iod could 'capture' the dfr> + * recieve lock. dfr> + */ "..., 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" Actually, under delayed write process, single iod keeps recive lock, but other iods can process its reply without block. /\ Hidetoshi Shimokawa \/ simokawa@sat.t.u-tokyo.ac.jp PGP public key: finger -l simokawa@sat.t.u-tokyo.ac.jp
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?9432.844966167>