Re: dm-mpath request merging concerns [was: Re: It's time to put together the schedule]

[Mike Snitzer <snitzer@redhat.com>]

On Mon, Feb 23 2015 at  1:34pm -0500,
Benjamin Marzinski <bmarzins@redhat.com> wrote:

> On Mon, Feb 23, 2015 at 11:18:36AM -0600, Mike Christie wrote:
> > 
> > If the device/transport is fast or the workload is low, the multipath_busy
> > never returns busy, then we can hit Hannes's issue. For 4 paths, we just
> > might not be able to fill up the paths and hit the busy check. With only 2
> > paths, we might be slow enough or the workload is heavy enough to keep the
> > paths busy and so we hit the busy check and do more merging.
> 
> Netapp is seeing this same issue.  It seems like we might want to make
> multipath_busy more aggressive about returning busy, which would
> probably require multipath tracking the size and frequency of the
> requests.  If it determines that it's getting a lot of requests that
> could have been merged, it could start throttling how fast requests are
> getting pulled off the queue, even there underlying paths aren't busy.

the ->busy() checks are just an extra check the shouldn't be the primary
method for governing the effectiveness of the DM-mpath queue's elevator.

I need to get back to basics to appreciate how the existing block layer
is able to have an effective elevator regardless of the device's speed.
And why isn't request-based DM able to just take advantage of it?

(my money is on request-based DM being overly clever but we'll see)