On Thu, May 20, 2010 at 04:01:55PM +0200, Corrado Zoccolo wrote:> On Thu, May 20, 2010 at 3:18 PM, Vivek Goyal <vgoyal@redhat.com> wrote:> > On Thu, May 20, 2010 at 01:51:49AM +0200, Corrado Zoccolo wrote:> > Hi Corrado,> >> > Deep queues can happen often on high end storage. One case I can think of is> > multiple kvm virt machines running and doing IO using AIO.> >> > I am not too keen on introducing a tunable at this point of time. Reason> > being that somebody having a SATA disk and driving deep queue depths is> > not very practical thing to do. At the same time we have fixed a theoritical> > problem in the past. If somebody really runs into the issue of deep queue> > starving other random IO, then we can fix it.> >> > Even if we have to fix it, I think instead of a tunable, a better solution> > would be to expire the deep queue after one round of dispatch (after> > having dispatched "quantum" number of requests from queue). That way no> > single sync-noidle queue will starve other queues and they will get to> > dispatch IO very nicely without intorducing any bottlenecks.> > Can you implement this solution in the patch? It seems that this will> solve both the performance issue as well as non-reintroducing the> theoretical starvation problem.> If we don't mind some more tree operations, the queue could be expired> at every dispatch (if there are other queues in the service tree),> instead of every quantum dispatches, to cycle through all no-idle> queues more quickly and more fairly.

Alright. Following is a copile tested only patch. I have yet to do thetesting to make sure it works. But I think it should address your concernof a deep queue starving other shallow sync-noidle queues.