Messages in this thread | | | Date | Wed, 16 Feb 2011 09:06:14 +0800 | From | Gui Jianfeng <> | Subject | Re: [PATCH 3/6 v4] cfq-iosched: Introduce vdisktime and io weight for CFQ queue |
| |
Vivek Goyal wrote: > On Tue, Feb 15, 2011 at 09:53:58AM +0800, Gui Jianfeng wrote: >> Vivek Goyal wrote: >>> On Sat, Feb 12, 2011 at 09:20:58AM +0800, Gui Jianfeng wrote: >>>> Vivek Goyal wrote: >>>>> On Thu, Feb 10, 2011 at 03:47:16PM +0800, Gui Jianfeng wrote: >>>>>> Introduce vdisktime and io weight for CFQ queue scheduling. Currently, io priority >>>>>> maps to a range [100,1000]. It also gets rid of cfq_slice_offset() logic and makes >>>>>> use the same scheduling algorithm as CFQ group does. This helps for CFQ queue and >>>>>> group scheduling on the same service tree. >>>>>> >>>>>> Signed-off-by: Gui Jianfeng <guijianfeng@cn.fujitsu.com> >>>>>> --- >>>>>> block/cfq-iosched.c | 219 +++++++++++++++++++++++++++++++++++++++------------ >>>>>> 1 files changed, 167 insertions(+), 52 deletions(-) >>>>>> >>>>>> diff --git a/block/cfq-iosched.c b/block/cfq-iosched.c >>>>>> index f3a126e..41cef2e 100644 >>>>>> --- a/block/cfq-iosched.c >>>>>> +++ b/block/cfq-iosched.c >>>>>> @@ -39,6 +39,13 @@ static const int cfq_hist_divisor = 4; >>>>>> */ >>>>>> #define CFQ_IDLE_DELAY (HZ / 5) >>>>>> >>>>>> +/* >>>>>> + * The base boosting value. >>>>>> + */ >>>>>> +#define CFQ_BOOST_SYNC_BASE (HZ / 10) >>>>>> +#define CFQ_BOOST_ASYNC_BASE (HZ / 25) >>>>>> + >>>>> These are same as cfq_slice_sync and cfq_slice_async. Looking at >>>>> boost logic, this is equivalent of starting a new queue/group as >>>>> if it is being requeued after conuming a full slice. So may be we can divide >>>>> it by some const number say 4 or something like that. This is a minor >>>>> point though as this algorimthm will kind of evolve and we will learn >>>>> what works best. >>>>> >>>>> Secondly, I think you wanted to SYNC vs ASYNC logic seem to be reversed. >>>>> We would like to give ASYNC queues higher boost (Put these farther in >>>>> tree) and lesser boost to SYNC queues. Looks like above constants will >>>>> do the reverse? >>>> Hi Vivek, >>>> >>>> Currently, SYNC and ASYNC queues are in different service tree, they don't >>>> impact each other. Here, I Really want use this logic. >>> Ok, SYNC and ASYNC are on separate service tree so their vtime are not >>> comparable (as of today, down the line one might want to look at those for >>> better workload selection logic). >>> >>> Anyway, because two are on seprate tree so why should we have separate >>> boosting constants for them? How does it help? >> Here if we are using CFQ_BOOST_SYNC_BASE for both, I think it might boost >> too much for an ASYNC cfqe as compare to others on the same service tree(async). >> So I make charging and boosting follow the same base. > > Ok, that makes sense. So as suggested in other mails, lets use a even > smaller base so that freshly backlogged queues get smaller vdisktimes > as compared to existing queues which are using disks for longer time.
Ok, It sounds making sense.
Thanks Gui
> > Thanks > Vivek >
| |