Messages in this thread | | | From | Jeff Moyer <> | Subject | Re: cfq-iosched preempt issues | Date | Wed, 02 Mar 2011 11:17:16 -0500 |
| |
Shaohua Li <shaohua.li@intel.com> writes:
> queue preemption is good for some workloads and not for others. With commit > f8ae6e3eb825, the impact is amplified. I currently have two issues with it: > 1. In a multi-threaded workload, each thread runs a random read/write (for > example, mmap write) with iodepth 1. I found the queue depth gets smaller > with commit f8ae6e3eb825. The reason is write gets preempted, so more threads > are waitting for write, and on the other hand, there are less threads doing > read. This will make the queue depth small, so performance drops a little. > So in this case, speed up write can speed up read too, but we can't detect > it.
I don't fully understand your workload. What is the aio-stress or fio command line/config file?
> 2. cfq_may_dispatch doesn't limit queue depth if the queue is the sole queue. > What about if there are two queues, one sync and one async? If the sync queue's > think time is small, we can treat it as the sole queue, because the sync queue > will preempt async queue, so we don't need care about the async queue's latency. > The issue exists before, but f8ae6e3eb825 amplifies it. Below is a patch for it.
I'm not sure I entirely agree with that reasoning. Do you have real workloads that are regressing due to this commit, or is it just these cooked up benchmarks?
Cheers, Jeff
| |