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@xxxxxxxxxx> 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 -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
