Re: [LSF/FS TOPIC] I/O performance isolation for shared storage

[Vivek Goyal <vgoyal@redhat.com>]

On Mon, Feb 07, 2011 at 11:40:26AM -0800, Chad Talbott wrote:
> On Mon, Feb 7, 2011 at 10:06 AM, Vivek Goyal <vgoyal@redhat.com> wrote:
> > On Fri, Feb 04, 2011 at 03:07:15PM -0800, Chad Talbott wrote:
> >> I'd like to hear more about this.
> >
> > If a group dispatches some IO and then it is empty, then it will be
> > deleted from service tree and when new IO comes in, it will be put
> > at the end of service tree. That way all the groups become more of
> > round robin and there is no service differentiation.
> >
> > I was thiking that when a group gets backlogged instead of putting
> > him at the end of service tree come up with a new mechanism of
> > where they are put at certain offset from the st->min_vdisktime. This
> > offset is more for high prio group and less for low prio group. That
> > way even if a group gets deleted and comes back again with more IO
> > there is a chance it gets schedled ahead of already queued low prio
> > group and we could see some service differentiation even with idling
> > disabled.
> 
> This is interesting.  I think Nauman may have come up with a different
> method to address similar concerns.  In his method, we remember a
> group's vdisktime even when they are removed from the service tree.
> This would lead fairness over too long of a time window implemented by
> itself.  Only when the disk becomes idle, we "forget" everyone's
> vdisktime.  We should be sending that patch out Real Soon Now, along
> with the rest.

I have thought about it in the past. I think there are still few
concerns there.

- How to determine which group's vdisktime is still valid and how to
  invalidate all the past vdisktimes.

- When idling is disabled, most likely groups will dispatch bunch of
  requests and go away. So slice used might be just 1 jiffy or even
  less. In that case all the groups then have same vdisktime at
  expiry and not service differentiation.

- Even if we reuse the previous disktime, most likely it is past
  st->min_vdisktime, which is an monotonically increasing number. How
  is that handled.

Thanks
Vivek