From owner-freebsd-lite2 Thu Oct 10 09:50:03 1996 Return-Path: owner-lite2 Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id JAA01210 for lite2-outgoing; Thu, 10 Oct 1996 09:50:03 -0700 (PDT) Received: from agora.rdrop.com (root@agora.rdrop.com [199.2.210.241]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id JAA01168 for ; Thu, 10 Oct 1996 09:49:59 -0700 (PDT) Received: from uno.sat.t.u-tokyo.ac.jp by agora.rdrop.com with smtp (Smail3.1.29.1 #17) id m0vBOIx-00093DC; Thu, 10 Oct 96 09:49 PDT Received: by uno.sat.t.u-tokyo.ac.jp (8.7.3+2.6Wbeta5/8.7.3) with ESMTP id BAA09434; Fri, 11 Oct 1996 01:49:27 +0900 (JST) To: Doug Rabson Cc: henrich@crh.cl.msu.edu, lite2@freebsd.org Subject: Re: Delayed write patch X-Mailer: Mew version 1.06 on Emacs 19.28.1, Mule 2.3 Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Date: Fri, 11 Oct 1996 01:49:27 +0900 Message-ID: <9432.844966167@sat.t.u-tokyo.ac.jp> From: Hidetoshi Shimokawa Sender: owner-lite2@freebsd.org X-Loop: FreeBSD.org Precedence: bulk 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