Messages in this thread | | | Date | Tue, 15 Feb 2011 09:53:58 +0800 | From | Gui Jianfeng <> | Subject | Re: [PATCH 3/6 v4] cfq-iosched: Introduce vdisktime and io weight for CFQ queue |
| |
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.
Thanks, Gui
> > Thanks > Vivek > -- > 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/ >
| |