On Fri, May 01, 2020 at 07:45:05PM +0200, Christoph Hellwig wrote: > On Fri, May 01, 2020 at 11:01:29PM +0800, Ming Lei wrote: > > > We cannot increase MAX_QUEUE arbitrarily as this is a compile time variable, > > > which seems to relate to a hardware setting. > > > > > > But I can see to update the reserved command functionality for allowing to > > > fetch commands from the normal I/O tag pool; in the case of LUN reset it > > > shouldn't make much of a difference as the all I/O is quiesced anyway. > > > > It isn't related with reset. > > > > This patch reduces active IO queue depth by 1 anytime no matter there is reset > > or not, and this way may cause performance regression. > > But isn't it the right thing to do? How else do we guarantee that > there always is a tag available for the LU reset? If that is case, some of these patches should be bug-fix, but nothing about this kind of comment is provided. If it is true, please update the commit log and explain the current issue in detail, such as, what is the side-effect of 'overwriting the original command'? And we might need to backport it to stable tree because storage error recovery is very key function. Even though it is true, still not sure if this patch is the correct way to fix the issue cause IO performance drop might be caused. Thanks, Ming
