On Fri, Aug 05, 2005 at 11:32:07AM -0500, James Bottomley wrote: > On Fri, 2005-08-05 at 21:33 +0900, Tejun Heo wrote: > > Here's the fix. It basically revives bqt->real_max_depth sans > > allocation optimization in init_tag_map. I've also added a comment > > explicitly noting that tag map cannot be shrunk to prevent other > > morons like me. :-( Please try this one and let me know how it works. > > If this is the correct fix, I'll repost properly to Jens and lkml with > > detailed explanation on how it was broken in the original code and how > > I broke it with my previous patch. Sorry. > > Actually, if you really want to adjust the array size downwards, there's > a way we can do it: > > - If the bits that would be lost on shrinkage are all zero at the time > blk_queue_resize_tags() is called, that means that there are no > outstanding tags up there and the array can be shrunk immediately. > > - If there are outstanding tags between the new and the old depth, the > array can be shrunk when the last one of these returns, say in > blk_rq_end_tag() > Hello, James. Yes, we can do that, but I'm not sure if that would be necessary. AFAIK, queues are normally not very deep and a tag only occupies one pointer and one bit. Also, the shrinking operation isn't very common, at least for traditional SPI devices and SATA drives, I think. Are newer SCSI devices (say, SAS/iSCSI) different? - like having very deep queue and needing dynamic queue depth adjustment? If that's the case, I think I can implement shrinking in a separate patch. (and try not to screw up this time ;-) Thank you. -- tejun - : send the line "unsubscribe linux-scsi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
