From mboxrd@z Thu Jan 1 00:00:00 1970 From: Vivek Goyal Subject: Re: [LSF/FS TOPIC] I/O performance isolation for shared storage Date: Mon, 7 Feb 2011 15:38:01 -0500 Message-ID: <20110207203801.GL7437@redhat.com> References: <20110204023144.GA30087@redhat.com> <20110207180647.GI7437@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: lsf-pc@lists.linuxfoundation.org, linux-fsdevel@vger.kernel.org To: Chad Talbott Return-path: Received: from mx1.redhat.com ([209.132.183.28]:10601 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752388Ab1BGUih (ORCPT ); Mon, 7 Feb 2011 15:38:37 -0500 Content-Disposition: inline In-Reply-To: Sender: linux-fsdevel-owner@vger.kernel.org List-ID: On Mon, Feb 07, 2011 at 11:40:26AM -0800, Chad Talbott wrote: > On Mon, Feb 7, 2011 at 10:06 AM, Vivek Goyal 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