From owner-freebsd-arch Wed Jun 28 23:15:18 2000 Delivered-To: freebsd-arch@freebsd.org Received: from fw.wintelcom.net (ns1.wintelcom.net [209.1.153.20]) by hub.freebsd.org (Postfix) with ESMTP id B352737B86C for ; Wed, 28 Jun 2000 23:15:14 -0700 (PDT) (envelope-from bright@fw.wintelcom.net) Received: (from bright@localhost) by fw.wintelcom.net (8.10.0/8.10.0) id e5T6FBk24268; Wed, 28 Jun 2000 23:15:11 -0700 (PDT) Date: Wed, 28 Jun 2000 23:15:10 -0700 From: Alfred Perlstein To: Marius Bendiksen Cc: freebsd-arch@FreeBSD.ORG Subject: Re: Alterations to vops Message-ID: <20000628231510.F275@fw.wintelcom.net> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: ; from mbendiks@eunet.no on Thu, Jun 29, 2000 at 07:18:37AM +0200 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG * Marius Bendiksen [000628 22:22] wrote: > After having discussed the issue of find(1) and similar processes > hogging CPU due to being very un-nice when stuck in these waiting > on BIO, I have, together with Brian Feldman, who first pointed it > out as a problem, come up with a suggested solution. > First off comes adding "off_t *offs" to the relevant vops. > This value would be initialized to VNOVAL by the caller, and then > be updated by the vops in subsequent calls. > Secondly, a new error value, ERETRY, would be added, which > would signify that the vop has not completed and should rather be > reissued. The libraries would do this transparently to the users. > This value is proposed rather than EAGAIN as there is no resource > shortage at all. > > This mechanism would also simplify the directory scanning in UFS, > at least somewhat. Can you elaborate on the problem you are describing? I'm not sure I understand besideds certain processes being able to hog the buffercache and filesystems. -Alfred To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message