James Smart wrote:
Well, I know there are fixed limits based on the context limits in their interface chips. Tachyons are a good example of this, especially some of the older ones. There are also a lot of arrays that are sold in fixed configurations so they don't have the variability you mention.
forgot one more - firmware algorithms that cap the limits... now the real reason for the reply...
... b) there's always questions on how/when you ramp up and at what rate, which is confused again if the queue full wasn't because of target-level resources. We also have to be careful
I realized after I wrote this, that I was implicitly assuming that you are part of a multi-initiator (which can include multiple path) environment. If you are the only initiator to the target, the algorithms can work fairly well to detect the max, and you can pin it - with a short performance reduction in the beginning. But, if part of a multi-initiator environment, you can get wild swings on what the ramp down moves to, which makes the ramp up more critical. It also leads to biasing toward initiators that have high loads oustanding. Any time your are waiting to ramp up, you are potentially at a lower performance. Granted, the fixed target limit doesn't work well in this case either, but admins are more agreeable to partition the physical target limit between the servers and let the luns share the server's target limit. Just a couple more reasons why, although the queue full seems a good approach, it's far harder to make it work well, and may need a couple of different algorithms. -- james s -- To unsubscribe from this list: 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
