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. > [..] >> There is interest in accounting for IO time, and ioprio doesn't >> provide a notion of "tagging" IO by submitter. > > I am curious to know how IO time can be accounted with deep queue depths > as once say 32 or more requests are in driver/device, we just don't > know which request consumed how much of actual time. Yes, that's a large problem. We would be interested in the partial solution that works against shallow queues. Thinking out loud: it occurs to me that without device support, some sort of device performance model might be hard to avoid when trying to understand the work incurred by a given request. Chad -- 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
