On Tue, May 22 2012 at 5:57am -0400, Jun'ichi Nomura <j-nomura@xxxxxxxxxxxxx> wrote: > On 05/22/12 18:13, James Bottomley wrote: > > Isn't a more understandable explanation: > > Thank you. That's quite elegant. > I replaced the description with it. > > > And please put a comment in the code as well otherwise someone will > > eventually send a "fix" for this because we're not paying attention to > > host busy (and I'll have forgotten about the issue by then and might > > apply it). > > Added the comment in code. > > > A final note is that this is more a band aid than a fix because this is > > still a congestion situation dm-mp should be aware of. > > Yes. To do that, we have to generalize the concept of "host" > and share it with block layer. > > Attached below is the revised patch. > > ---------------------------------------------------------- > [PATCH v2] scsi: Fix dm-multipath starvation when scsi host is busy > > block congestion control doesn't have any concept of fairness across > multiple queues. This means that if SCSI reports the host as busy in > the queue congestion control it can result in an unfair starvation > situation in dm-mp if there are multiple multipath devices on the same > host. For example: > http://www.redhat.com/archives/dm-devel/2012-May/msg00123.html > > The fix for this is to report only the sdev busy state (and ignore the > host busy state) in the block congestion control call back. > The host is still congested, but the SCSI subsystem will sort out the > congestion in a fair way because it knows the relation between the > queues and the host. > > Reported-by: Bernd Schubert <bernd.schubert@xxxxxxxxxxxxxxxxxx> > Tested-by: Bernd Schubert <bernd.schubert@xxxxxxxxxxxxxxxxxx> > Signed-off-by: Jun'ichi Nomura <j-nomura@xxxxxxxxxxxxx> > Cc: James Bottomley <James.Bottomley@xxxxxxxxxxxxxxxxxxxxx> > Cc: Mike Snitzer <snitzer@xxxxxxxxxx> Acked-by: Mike Snitzer <snitzer@xxxxxxxxxx> -- 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
