Currently we idle on sequential queues and allow dispatch from a singlequeue and that can become a bottleneck on higher end storage. For exampleon my HP EVA, I can run multiple sequential streams and achieve top BWof around 350 MB/s. But with CFQ, dispatching from single queue does notkeep the array busy (limits to 150-180 MB/s with 4 or 8 processes).

One approach to solve this issue is simply use slice_idle = 0. But thisalso takes away the any service differentiation between groups.

This patch implements a new tunable "group_idle". This is similar toslice_idle but it forces idling at cfq group level and not at cfq queuelevel. So the idea is that one can run with slice_idle = 0 and group_idle= 8, so that we don't idle on individual queues in the group but idleon the group and still keep the IO controller working.

Not idling on individual queues in the group will dispatch requests frommultiple queues in the group at the same time and achieve higher throughputon higher end storage.

I have done some testing with multiple sequential readers using fio in twogroups of weights 100 and 200. I run 1, 2, 4, 8 sequential readers in twogroups. Group names are test1 and test2 and throughputs are in KB/s.