On Fri, Apr 08 2016 at 2:58pm -0400, Mike Snitzer <snitzer@xxxxxxxxxx> wrote: > The DM multipath service-time path-selector has historically tracked the > amount of outstanding IO per path and used that to approximate the > service-time of each path. In practice this has shown itself to work > fairly well but we can do better by measuring the actual service-time > during IO completion and using it as the basis for path selection. > > Measuring the actual service-time is still prone to inaccuracies given > that service-times vary with IO size. But to counter any potential for > drawing incorrect conclusions about the service-times of a given path > the measured service-times are reset periodically. > > This approach has provided a 10% increase in the selection of a path > that was forcibly made to be less loaded than the alternative path. > > Reported-by: Todd Gill <tgill@xxxxxxxxxx> > Signed-off-by: Mike Snitzer <snitzer@xxxxxxxxxx> It should be noted that I have not looked at the implications on actual throughput or system load. But I wanted to get this RFC out to see what others thought about making dm-service-time more intuitive in its implementation. Junichi, it'd also be great if you could provide historic context for why you elected to approximate the service-time based on outstanding IO rather than measure the actual service-time of each path. Thanks, Mike -- dm-devel mailing list dm-devel@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/dm-devel
