Date: Thu, 2 Jan 1997 16:54:23 -0500 (EST) From: Peter Dufault <dufault@hda.com> To: joerg_wunsch@uriah.heep.sax.de Cc: freebsd-scsi@FreeBSD.ORG Subject: Re: Ideas on CD changers sought Message-ID: <199701022154.QAA23215@hda.hda.com> In-Reply-To: <199701021747.SAA08128@uriah.heep.sax.de> from J Wunsch at "Jan 2, 97 06:47:14 pm"
next in thread | previous in thread | raw e-mail | index | archive | help
> Something that's on my back-burner for quite some time now: > However, there's still one big problem: concurrent access to the > various CDs. Even two processes using two CDs concurrently now cause > the device to basically start thrashing: the accesses to the media get > intermixed to a degree where the device is finally mostly busy with > swapping media, instead of transferring data. Now the $ 9.99 question > is: what's the best way to avoid this, so some more transfers will be > queued up for one device first, before the LUNs should change? Should > this be CD driver specific, or are other drivers also in need for > this? How about round robin scheduling the platters, maybe with hysteresis on platter switching? Add a "changer queue" that is a queue of CD start queues to schedule the changer resource. A changerstart routine can then round robin schedule across the active platters. Enqueue your buffers into the CD start queue the way it is now. When a CD start queue goes from empty to not-empty, add the CD start queue to the end of the changer queue, and call changerstart if the changer queue went empty to not-empty. Have changerstart schedule up to N transfers in a row for a given unit by calling a derivation of the existing cdstart. If N counts down take the CD start queue off and enqueue it again at the tail of the changer queue and move to the next CD start queue. You want to select N to be a number that gives you decent utilization, maybe enough transfers to take twice as long as the change mechanism. You can still come up with loads that will thrash this. You could add hysteresis to the platter switching with a minimum-time-at-a-platter timeout. If you're feeling ambitious, see if you can set up the CD commands in cd_strategy instead of cdstart and make the queue handling independent of the device type (and outside of the interrupt). This packages up the I/O policy and makes it easier to change in the future. Peter -- Peter Dufault (dufault@hda.com) Realtime Machine Control and Simulation HD Associates, Inc. Voice: 508 433 6936
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199701022154.QAA23215>