similar to: No subject

This patchset expands traditional CFQ scheduler in order to support cgroups, and improves old version. Improvements are as following. * Modularizing our new CFQ scheduler. The expanded CFQ scheduler is registered/unregistered as new I/O elevator scheduler called "cfq-cgroups". By this, the traditional CFQ scheduler, which does not handle cgroups, and our new CFQ

This patchset expands traditional CFQ scheduler in order to support cgroups, and improves old version. Improvements are as following. * Modularizing our new CFQ scheduler. The expanded CFQ scheduler is registered/unregistered as new I/O elevator scheduler called "cfq-cgroups". By this, the traditional CFQ scheduler, which does not handle cgroups, and our new CFQ

Hi, If you are not already tired of so many io controller implementations, here is another one. This is a very eary very crude implementation to get early feedback to see if this approach makes any sense or not. This controller is a proportional weight IO controller primarily based on/inspired by dm-ioband. One of the things I personally found little odd about dm-ioband was need of a dm-ioband

Hi, If you are not already tired of so many io controller implementations, here is another one. This is a very eary very crude implementation to get early feedback to see if this approach makes any sense or not. This controller is a proportional weight IO controller primarily based on/inspired by dm-ioband. One of the things I personally found little odd about dm-ioband was need of a dm-ioband

On 2014-06-25 20:08, Ming Lei wrote: > Hi, > > These patches try to support multi virtual queues(multi-vq) in one > virtio-blk device, and maps each virtual queue(vq) to blk-mq's > hardware queue. > > With this approach, both scalability and performance on virtio-blk > device can get improved. > > For verifying the improvement, I implements virtio-blk multi-vq

Hi, This patches try to support multi virtual queues(multi-vq) in one virtio-blk device, and maps each virtual queue(vq) to blk-mq's hardware queue. With this approach, both scalability and performance problems on virtio-blk device get improved. For verifying the improvement, I implements virtio-blk multi-vq over qemu's dataplane feature, and both handling host notification from each vq

Hi, This patches try to support multi virtual queues(multi-vq) in one virtio-blk device, and maps each virtual queue(vq) to blk-mq's hardware queue. With this approach, both scalability and performance problems on virtio-blk device get improved. For verifying the improvement, I implements virtio-blk multi-vq over qemu's dataplane feature, and both handling host notification from each vq

Hi Jeff, On 07/03/2010 03:58 AM, Jeff Moyer wrote: > Hi, > > Running iozone or fs_mark with fsync enabled, the performance of CFQ is > far worse than that of deadline for enterprise class storage when dealing > with file sizes of 8MB or less. I used the following command line as a > representative test case: > > fs_mark -S 1 -D 10000 -N 100000 -d /mnt/test/fs_mark -s

Hi, These patches try to support multi virtual queues(multi-vq) in one virtio-blk device, and maps each virtual queue(vq) to blk-mq's hardware queue. With this approach, both scalability and performance on virtio-blk device can get improved. For verifying the improvement, I implements virtio-blk multi-vq over qemu's dataplane feature, and both handling host notification from each vq and

Hi, These patches try to support multi virtual queues(multi-vq) in one virtio-blk device, and maps each virtual queue(vq) to blk-mq's hardware queue. With this approach, both scalability and performance on virtio-blk device can get improved. For verifying the improvement, I implements virtio-blk multi-vq over qemu's dataplane feature, and both handling host notification from each vq and

Hi, These patches try to support multi virtual queues(multi-vq) in one virtio-blk device, and maps each virtual queue(vq) to blk-mq's hardware queue. With this approach, both scalability and performance on virtio-blk device can get improved. For verifying the improvement, I implements virtio-blk multi-vq over qemu's dataplane feature, and both handling host notification from each vq and

Hi, These patches try to support multi virtual queues(multi-vq) in one virtio-blk device, and maps each virtual queue(vq) to blk-mq's hardware queue. With this approach, both scalability and performance on virtio-blk device can get improved. For verifying the improvement, I implements virtio-blk multi-vq over qemu's dataplane feature, and both handling host notification from each vq and

On Thu, Jun 26, 2014 at 5:41 PM, Ming Lei <ming.lei at canonical.com> wrote: > Hi, > > These patches try to support multi virtual queues(multi-vq) in one > virtio-blk device, and maps each virtual queue(vq) to blk-mq's > hardware queue. > > With this approach, both scalability and performance on virtio-blk > device can get improved. > > For verifying the

On 2014-06-30 19:36, Ming Lei wrote: > Hi Jens and Rusty, > > On Thu, Jun 26, 2014 at 8:04 PM, Ming Lei <ming.lei at canonical.com> wrote: >> On Thu, Jun 26, 2014 at 5:41 PM, Ming Lei <ming.lei at canonical.com> wrote: >>> Hi, >>> >>> These patches try to support multi virtual queues(multi-vq) in one >>> virtio-blk device, and maps

Hi Jens and Rusty, On Thu, Jun 26, 2014 at 8:04 PM, Ming Lei <ming.lei at canonical.com> wrote: > On Thu, Jun 26, 2014 at 5:41 PM, Ming Lei <ming.lei at canonical.com> wrote: >> Hi, >> >> These patches try to support multi virtual queues(multi-vq) in one >> virtio-blk device, and maps each virtual queue(vq) to blk-mq's >> hardware queue. >>

Hi Jens and Rusty, On Thu, Jun 26, 2014 at 8:04 PM, Ming Lei <ming.lei at canonical.com> wrote: > On Thu, Jun 26, 2014 at 5:41 PM, Ming Lei <ming.lei at canonical.com> wrote: >> Hi, >> >> These patches try to support multi virtual queues(multi-vq) in one >> virtio-blk device, and maps each virtual queue(vq) to blk-mq's >> hardware queue. >>

This patch introcude cfq_cgroup structure which is type for group control within expanded CFQ scheduler. In addition, the cfq_cgroup structure has "ioprio" entry which is preference of group for I/O. Signed-off-by: Satoshi UCHIDA <s-uchida at ap.jp.nec.com> --- block/cfq-cgroup.c | 148 +++++++++++++++++++++++++++++++++++++++++

This patch add a interface for parameter of cfq driver data. Signed-off-by: Satoshi UCHIDA <s-uchida at ap.jp.nec.com> --- block/cfq-cgroup.c | 59 +++++++++++++++++++++++++++++++++++++++++++++++++++- 1 files changed, 58 insertions(+), 1 deletions(-) diff --git a/block/cfq-cgroup.c b/block/cfq-cgroup.c index 4938fa0..776874d 100644 --- a/block/cfq-cgroup.c +++

This patch introduces iprio class for cfq data control layer. By applying this patch, controller can also handle the RT/IDLE properties among groups. Signed-off-by: Satoshi UCHIDA <s-uchida at ap.jp.nec.com> --- block/cfq-cgroup.c | 344 +++++++++++++++++++++++++------------------ include/linux/cfq-iosched.h | 1 + 2 files changed, 203 insertions(+), 142 deletions(-)

This patch introduces iprio class for cfq data control layer. By applying this patch, controller can also handle the RT/IDLE properties among groups. Signed-off-by: Satoshi UCHIDA <s-uchida at ap.jp.nec.com> --- block/cfq-cgroup.c | 344 +++++++++++++++++++++++++------------------ include/linux/cfq-iosched.h | 1 + 2 files changed, 203 insertions(+), 142 deletions(-)