Date: Thu, 6 Jul 2000 16:01:20 -0700 From: Alfred Perlstein <bright@wintelcom.net> To: Bill Fumerola <billf@chimesnet.com> Cc: Marius Bendiksen <mbendiks@eunet.no>, freebsd-arch@FreeBSD.ORG Subject: Re: Alterations to vops Message-ID: <20000706160120.Z25571@fw.wintelcom.net> In-Reply-To: <20000706173234.V4034@jade.chc-chimes.com>; from billf@chimesnet.com on Thu, Jul 06, 2000 at 05:32:34PM -0400 References: <20000628231510.F275@fw.wintelcom.net> <Pine.BSF.4.05.10007062327020.68909-100000@login-1.eunet.no> <20000706173234.V4034@jade.chc-chimes.com>
next in thread | previous in thread | raw e-mail | index | archive | help
* Bill Fumerola <billf@chimesnet.com> [000706 14:33] wrote: > On Thu, Jul 06, 2000 at 11:29:26PM +0200, Marius Bendiksen wrote: > > > 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. > > > > The problem lies, as I understand it (ask Feldman for details) in that a > > find(1) or similar process will cause a lot of work to be done in kernel > > space, which means the scheduler is not going to clamp down on it. Also, > > it apparently hogs buffercache and I/O bandwidth. Changing these VOPs to > > be incremental would solve the problem. > > My systems get to the point of unusability when find(1) or cvsup(1) are > running. These things should be getting scheduled way back, but when > I hit 'i' in vi, it can take 30 seconds for it to switch to insert mode. > > These are not wimpy machines either. The disks are busy and vi most likely is doing an IO request, either implement a per-process buffer high water mark or deal with it. :) -Alfred To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20000706160120.Z25571>