From owner-freebsd-arch Fri Jul 7 14:46:21 2000 Delivered-To: freebsd-arch@freebsd.org Received: from smtp05.primenet.com (smtp05.primenet.com [206.165.6.135]) by hub.freebsd.org (Postfix) with ESMTP id 04B5C37C0A8 for ; Fri, 7 Jul 2000 14:46:16 -0700 (PDT) (envelope-from tlambert@usr05.primenet.com) Received: (from daemon@localhost) by smtp05.primenet.com (8.9.3/8.9.3) id OAA25725; Fri, 7 Jul 2000 14:46:33 -0700 (MST) Received: from usr05.primenet.com(206.165.6.205) via SMTP by smtp05.primenet.com, id smtpdAAADdaWgY; Fri Jul 7 14:46:22 2000 Received: (from tlambert@localhost) by usr05.primenet.com (8.8.5/8.8.5) id OAA14015; Fri, 7 Jul 2000 14:45:56 -0700 (MST) From: Terry Lambert Message-Id: <200007072145.OAA14015@usr05.primenet.com> Subject: Re: Alterations to vops To: mbendiks@eunet.no (Marius Bendiksen) Date: Fri, 7 Jul 2000 21:45:56 +0000 (GMT) Cc: bright@wintelcom.net (Alfred Perlstein), billf@chimesnet.com (Bill Fumerola), freebsd-arch@FreeBSD.ORG In-Reply-To: from "Marius Bendiksen" at Jul 07, 2000 02:58:32 PM X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > 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. :) > > This could be done by an IO scheduler. This is a cache starvation issue, where an I/O bound process starves a CPU bound process. A fair-share scheduler or I/O scheduler approach will only allow a program to steal the pages back from the culprit program, not deal with the underlying problem. It's possible to burn CPU an I/O cycles on this, and get what the use perceives as improved interactive performance, but in reality what the user is getting is some fraction less of a machine than that which they paid for. The most naieve fix for this is per vnode working set quotas, which would be implemented by causing the process to steal pages from itself, rather than from other processes, once some high water mark less than system resource limits has been reached. I tested this in a UnixWare kernel with much better results than the "fixd scheduling class" scheduler they ended up using to get X Windows interactive response (move mouse, wiggle cursor) to be better. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message