From owner-freebsd-current Mon Nov 13 23:41:42 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id XAA05810 for current-outgoing; Mon, 13 Nov 1995 23:41:42 -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 XAA05803 for ; Mon, 13 Nov 1995 23:41:38 -0800 Received: (from julian@localhost) by ref.tfs.com (8.6.12/8.6.9) id XAA26852; Mon, 13 Nov 1995 23:39:53 -0800 From: Julian Elischer Message-Id: <199511140739.XAA26852@ref.tfs.com> Subject: Re: Disk I/O that binds To: davidg@Root.COM Date: Mon, 13 Nov 1995 23:39:53 -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: 1272 Sender: owner-current@freebsd.org Precedence: bulk hmm a little radical but it'd be very fair.. SLOW, but very fair :) I was thinking that the disksort might be convinced to not put the next block at the start of the queue if the 3rd entry has seen more than (say) 10 blocks queuejumped in front of it.. hmmm we would add a pointer to the "one after next" every time something gets put in front of it, a counter is incremented. if the counter reaches some value, we don't do that any more... when it finally gets run, we reset the pointer and counter (add glue logic for startup and boundary conditions etc..) it could be implimented pretty simply.. (and would be quick) I may wander off and see what it would take.... unfortunatly we don't have a generic 'take it off the disk queue' routine, just one for puting it on.. :( (damn!) I guess we would have to change sd.c and wd.c too (oh poo) > > >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 >