Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753175AbYKZWQ5 (ORCPT ); Wed, 26 Nov 2008 17:16:57 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1752028AbYKZWQs (ORCPT ); Wed, 26 Nov 2008 17:16:48 -0500 Received: from ms01.sssup.it ([193.205.80.99]:59725 "EHLO sssup.it" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1751847AbYKZWQr (ORCPT ); Wed, 26 Nov 2008 17:16:47 -0500 Date: Wed, 26 Nov 2008 23:21:03 +0100 From: Fabio Checconi To: Nauman Rafique Cc: Paolo Valente , Vivek Goyal , Ryo Tsuruta , linux-kernel@vger.kernel.org, containers@lists.linux-foundation.org, virtualization@lists.linux-foundation.org, jens.axboe@oracle.com, taka@valinux.co.jp, righi.andrea@gmail.com, s-uchida@ap.jp.nec.com, fernando@oss.ntt.co.jp, balbir@linux.vnet.ibm.com, akpm@linux-foundation.org, menage@google.com, ngupta@google.com, riel@redhat.com, jmoyer@redhat.com, peterz@infradead.org Subject: Re: [patch 0/4] [RFC] Another proportional weight IO controller Message-ID: <20081126222103.GD29897@gandalf.sssup.it> References: <20081113221304.GH7542@redhat.com> <20081120.182053.220301508585579959.ryov@valinux.co.jp> <20081120134701.GB29306@redhat.com> <20081125.113359.623571555980951312.ryov@valinux.co.jp> <20081125162720.GH341@redhat.com> <492D57E1.5090608@unimore.it> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 4651 Lines: 91 > From: Nauman Rafique > Date: Wed, Nov 26, 2008 11:41:46AM -0800 > > On Wed, Nov 26, 2008 at 6:06 AM, Paolo Valente wrote: > > Fabio and I are a little bit worried about the fact that the problem > > of working in the time domain instead of the service domain is not > > being properly dealt with. Probably we did not express ourselves very > > clearly, so we will try to put in more practical terms. Using B-WF2Q+ > > in the time domain instead of using CFQ (Round-Robin) means introducing > > higher complexity than CFQ to get almost the same service properties > > of CFQ. With regard to fairness (long term) B-WF2Q+ in the time domain > > Are we talking about a case where all the contenders have equal > weights and are continuously backlogged? That seems to be the only > case when B-WF2Q+ would behave like Round-Robin. Am I missing > something here? > It is the case with equal weights, but it is really a common one. > I can see that the only direct advantage of using WF2Q+ scheduling is > reduced jitter or latency in certain cases. But under heavy loads, > that might result in request latencies seen by RT threads to be > reduced from a few seconds to a few msec. > > > has exactly the same (un)fairness problems of CFQ. As far as bandwidth > > differentiation is concerned, it can be obtained with CFQ by just > > increasing the time slice (e.g., double weight => double slice). This > > has no impact on long term guarantees and certainly does not decrease > > the throughput. > > > > With regard to short term guarantees (request completion time), one of > > the properties of the reference ideal system of Wf2Q+ is that, assuming > > for simplicity that all the queues have the same weight, as the ideal > > system serves each queue at the same speed, shorter budgets are completed > > in a shorter time intervals than longer budgets. B-WF2Q+ guarantees > > O(1) deviation from this ideal service. Hence, the tight delay/jitter > > measured in our experiments with BFQ is a consequence of the simple (and > > probably still improvable) budget assignment mechanism of (the overall) > > BFQ. In contrast, if all the budgets are equal, as it happens if we use > > time slices, the resulting scheduler is exactly a Round-Robin, again > > as in CFQ (see [1]). > > Can the budget assignment mechanism of BFQ be converted to time slice > assignment mechanism? What I am trying to say here is that we can have > variable time slices, just like we have variable budgets. > Yes, it could be converted, and it would do in the time domain the same differentiation it does now in the service domain. What we would lose in the process is the fairness in the service domain. The service properties/guarantees of the resulting scheduler would _not_ be the same as the BFQ ones. Both long term and short term guarantees would be affected by the unfairness given by the different service rate experienced by the scheduled entities. > > > > Finally, with regard to completion time delay differentiation through > > weight differentiation, this is probably the only case in which B-WF2Q+ > > would perform better than CFQ, because, in case of CFQ, reducing the > > time slices may reduce the throughput, whereas increasing the time slice > > would increase the worst-case delay/jitter. > > > > In the end, BFQ succeeds in guaranteeing fairness (or in general the > > desired bandwidth distribution) because it works in the service domain > > (and this is probably the only way to achieve this goal), not because > > it uses WF2Q+ instead of Round-Robin. Similarly, it provides tight > > delay/jitter only because B-WF2Q+ is used in combination with a simple > > budget assignment (differentiation) mechanism (again in the service > > domain). > > > > [1] http://feanor.sssup.it/~fabio/linux/bfq/results.php > > > > -- > > ----------------------------------------------------------- > > | Paolo Valente | | > > | Algogroup | | > > | Dip. Ing. Informazione | tel: +39 059 2056318 | > > | Via Vignolese 905/b | fax: +39 059 2056199 | > > | 41100 Modena | | > > | home: http://algo.ing.unimo.it/people/paolo/ | > > ----------------------------------------------------------- > > > > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/