Date: Mon, 13 Nov 1995 23:39:53 -0800 (PST) From: Julian Elischer <julian@ref.tfs.com> To: davidg@Root.COM Cc: uhclem%nemesis@fw.ast.com, simonm@dcs.gla.ac.uk, current@freebsd.org Subject: Re: Disk I/O that binds Message-ID: <199511140739.XAA26852@ref.tfs.com> In-Reply-To: <199511140715.XAA00155@corbin.Root.COM> from "David Greenman" at Nov 13, 95 11:15:00 pm
next in thread | previous in thread | raw e-mail | index | archive | help
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 >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199511140739.XAA26852>