From owner-freebsd-current Mon Nov 13 23:26:54 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id XAA04414 for current-outgoing; Mon, 13 Nov 1995 23:26:54 -0800 Received: from ref.tfs.com (ref.tfs.com [140.145.254.251]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id XAA04408 for ; Mon, 13 Nov 1995 23:26:50 -0800 Received: (from julian@localhost) by ref.tfs.com (8.6.12/8.6.9) id XAA26807; Mon, 13 Nov 1995 23:25:13 -0800 From: Julian Elischer Message-Id: <199511140725.XAA26807@ref.tfs.com> Subject: Re: Disk I/O that binds To: davidg@Root.COM Date: Mon, 13 Nov 1995 23:25:12 -0800 (PST) Cc: uhclem%nemesis@fw.ast.com, simonm@dcs.gla.ac.uk, current@freebsd.org In-Reply-To: <199511140715.XAA00155@corbin.Root.COM> from "David Greenman" at Nov 13, 95 11:15:00 pm X-Mailer: ELM [version 2.4 PL24] Content-Type: text Content-Length: 1292 Sender: owner-current@freebsd.org Precedence: bulk Actually here's an answer that might tackle it from another point.. if the raised priority that a process get's after getting a block is lower that the raised priority that a process gets after being suspended for a second or two, then in a busy system, whenever processes start getting held up the hog process will start to lose out a little more.. and maybe if it get's its read of the read-ahead buffer in just a little later, the head might have got a chance to get past it in which case it will have to go all the way around again.. at least in this method, an un busy system has less degradation.. processes that read a lot are constantly cycling into high priority after every read, but the sleeps are so short that these processes are basically permanently at raised priority.. especially with read-ahead and track caches making the disks so dammed fast > > >Another answer may be in the way we allocate blocks on the disk.. > >maybe we should allocate less on any particular cylinder group and > >jump around more often??? > > > >(might be an easier answer :) > > Oh, I know, let's allocate all the blocks in reverse order - 7219 7218 7217, > etc. ...or better yet, let's use the new /dev/random driver to generate a > block list. Yeah, I *like* that idea. :-) > > -DG >