Date: Thu, 21 Mar 1996 16:16:21 +0100 From: se@zpr.uni-koeln.de (Stefan Esser) To: "Justin T. Gibbs" <gibbs@freefall.freebsd.org> Cc: FreeBSD-scsi@freefall.freebsd.org, Ulrich.Windl@rz.uni-regensburg.de Subject: Re: Simple Tagged Commands and Starvation Message-ID: <199603211516.AA19099@Sisyphos> In-Reply-To: "Justin T. Gibbs" <gibbs@freefall.freebsd.org> "Simple Tagged Commands and Starvation" (Mar 20, 22:28)
next in thread | previous in thread | raw e-mail | index | archive | help
On Mar 20, 22:28, "Justin T. Gibbs" wrote: } Subject: Simple Tagged Commands and Starvation } I would like to hear other's opinions on this subject and possible ways to } avoid the problem without arbitrarily penalizing commands entered into the } queue. The problem may be agravated in Linux by using a large number of } tags and a short timeout (Ulrich, FreeBSD uses a 10sec timeout and the two } drivers that use tagged queueing default to 4 tags max per target which } seems to offer the best performance under various benchmarks -- I have no } idea what Linux uses). Since we are planning to push the dictation of } queue message types up into the generic SCSI layer, it may turn out that we } can solve this problem solely by enforcing ordered tags for syncronous } writes. I'm also wading through the SCSI spec again in the hopes of an } alternate way out, but it doesn't look good. I've received mail from Gerard Roudier (who ported the FreeBSD NCR driver to Linux) on this topic, a few weeks ago, and he suggested a fix. Linux has a 5 second timeout on read and write commands, and he found that on every Bonnie run, he got a few (soft) timeouts from the driver, i.e. the drive did delay execution of a tagged command for more than 5 seconds. Since the NCR driver polls the list of currently executing commands once a second anyway, he suggested using an ORDERED TAG for the next command sent to that target, if any command is not completed, two seconds before its timer expires. This would place a barrier in the SCSI command stream. I.e. the next command issued would not execute before all previously issued commands are complete. And two seconds should be sufficient to complete far more than 4 outstanding commands (it should suffice for 100, in fact :) I had been thinking about a simpler algorithm: Have a bit mask, and reset it to all zeroes, once a second. When a tag message is required, and there is a 0 at the position corresponding to that target, then use an ORDERED TAG and set the bit to one. (In fact, this bit should be set to one, when ever a ordered tag message is sent :) (The ORDERED TAG applies to a I_T_L_Q nexus, i.e. apllies to LUNs, not targets, but I've yet to see a single multi-LUN device that supports tagged commands). This would make the driver use at most one ordered tag per second, for a negligable loss of performance, and this (or some variation of the theme) apppears to be a solution that could be implemented in the GENERIC SCSI code ... Regards, STefan -- Stefan Esser, Zentrum fuer Paralleles Rechnen Tel: +49 221 4706021 Universitaet zu Koeln, Weyertal 80, 50931 Koeln FAX: +49 221 4705160 ============================================================================== http://www.zpr.uni-koeln.de/~se <se@ZPR.Uni-Koeln.DE>
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199603211516.AA19099>