> From: Nauman Rafique <nauman@xxxxxxxxxx> > Date: Tue, Nov 18, 2008 02:33:19PM -0800 > > On Tue, Nov 18, 2008 at 4:05 AM, Fabio Checconi <fchecconi@xxxxxxxxx> wrote: ... > > it should be possible without altering the code. The slices can be > > assigned in the time domain using big values for max_budget. The logic > > is: each process is assigned a budget (in the range [max_budget/2, max_budget], > > choosen from the feedback mechanism, driven in __bfq_bfqq_recalc_budget()), > > and if it does not complete it in timeout_sync milliseconds, it is > > charged a fixed amount of sectors of service. > > > > Using big values for max_budget (where big means greater than two > > times the number of sectors the hard drive can transfer in timeout_sync > > milliseconds) makes the budgets always to time out, so the disk time > > is scheduled in slices of timeout_sync. > > > > However this is just a temporary workaround to do some basic testing. > > > > Modifying the scheduler to support time slices instead of sector > > budgets would indeed simplify the code; I think that the drawback > > would be being too unfair in the service domain. Of course we > > have to consider how much is important to be fair in the service > > domain, and how much added complexity/new code can we accept for it. > > > > [ Better service domain fairness is one of the main reasons why > > we started working on bfq, so, talking for me and Paolo it _is_ > > important :) ] > > > > I have to think a little bit on how it would be possible to support > > an option for time-only budgets, coexisting with the current behavior, > > but I think it can be done. > > I think "time only budget" vs "sector budget" is dependent on the > definition of fairness: do you want to be fair in the time that is > given to each cgroup or fair in total number of sectors transferred. > And the appropriate definition of fairness depends on how/where the IO > scheduler is used. Do you think the work-around that you mentioned > would have a significant performance difference compared to direct > built-in support? > In terms of throughput, it should not have any influence, since tasks would always receive a full timeslice. In terms of latency it would bypass completely the feedback mechanism, and that would have a negative impact (basically the scheduler would not be able to differentiate between tasks with the same weight but with different interactivity needs). In terms of service fairness it is a little bit hard to say, but I would not expect anything near to what can be done with a service domain approach, independently from the scheduler used. _______________________________________________ Virtualization mailing list Virtualization@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/virtualization
