On Tue, Jan 12, 2010 at 11:48:20PM +0800, Vivek Goyal wrote:> On Tue, Jan 12, 2010 at 11:07:56AM +0800, Shaohua Li wrote:> > [..]> > > > > > > I think this patch breaks the meaning of cfq_quantum? Now we can allow> > > > > > > dispatch of more requests from the same queue. I had kind of liked the> > > > > > > idea of respecting cfq_quantum. Especially it can help in testing. With> > > > > > > this patch cfq_quantum will more or less loose its meaning.> > > > > > cfq_quantum will still be enforced at the end of the slice, so its> > > > > > meaning of how many requests can be still pending when you finish your> > > > > > slice is preserved.> > > > > > > > > > Not always and it will depend how accurate your approximation of service> > > > > time is. If per request completion time is more than approximation (in> > > > > this case slice_idle), than you will end up with more requests in dispatch> > > > > queue from one cfqq at the time of slice expiry.> > > > we use slice_idle for a long time and no complain. So assume the approximation> > > > of service time is good.> > > > > > slice_idle is a variable and user can easily change it to 1ms and even 0.> > > In that case you will be theoritically be ready to dispatch 100/1 requests> > > from the cfqq?> > User changing it should know what he does. A less-experienced user can mess a lot> > of things, which we don't care. > > > > The point is that there is no obivious co-relation between slice_idle and> cfq_quantum. Even an experienced user would not expect that changing> slice_idle silently will enable dispatching more requests from each cfqq.Agree slice_idle hasn't relationship with cfq_quantum. Yes, there are more requestsdispatched, but it shouldn't impact user experience. If it does, then the patch fails.