search for: hirokazu

Hi everyone, This is a new release of dm-ioband and bio-cgroup. With this release, the overhead of bio-cgroup is significantly reduced and the accuracy of block I/O tracking is much improved. These patches are for 2.6.28-rc2-mm1. Enjoy it! dm-ioband ========= Dm-ioband is an I/O bandwidth controller implemented as a device-mapper driver, which gives specified bandwidth to each job running on

Hi everyone, This is a new release of dm-ioband and bio-cgroup. With this release, the overhead of bio-cgroup is significantly reduced and the accuracy of block I/O tracking is much improved. These patches are for 2.6.28-rc2-mm1. Enjoy it! dm-ioband ========= Dm-ioband is an I/O bandwidth controller implemented as a device-mapper driver, which gives specified bandwidth to each job running on

Hi everyone, This is a new release of dm-ioband and bio-cgroup. With this release, the overhead of bio-cgroup is significantly reduced and the accuracy of block I/O tracking is much improved. These patches are for 2.6.28-rc2-mm1. Enjoy it! dm-ioband ========= Dm-ioband is an I/O bandwidth controller implemented as a device-mapper driver, which gives specified bandwidth to each job running on

.... Some may just modify the sector numbers of I/O requests or may create a new I/O request themselves. Others such as md-raid5 have their own queues to control I/Os, where A write request may cause several read requests and have to wait for their completions before the actual write starts. Thanks, Hirokazu Takahashi.

...nel. This is impossible because every linux box has various number of disks. So you think it may be possible to make each cgroup have lots of control files for each device as a workaround. But it isn't allowed to add/remove control files when some devices are hot-added or hot-removed. Thanks, Hirokazu Takahashi.

...which thread is doing what kind of job in the application. We can just leave this issue to these type of applications, can we? I guess most of this kind of applications must have been well designed already. What do you think if we just leave it as it is and keep the code simple? Thanks, Hirokazu Takahashi.

...which thread is doing what kind of job in the application. We can just leave this issue to these type of applications, can we? I guess most of this kind of applications must have been well designed already. What do you think if we just leave it as it is and keep the code simple? Thanks, Hirokazu Takahashi.

.... Some may just modify the sector numbers of I/O requests or may create a new I/O request themselves. Others such as md-raid5 have their own queues to control I/Os, where A write request may cause several read requests and have to wait for their completions before the actual write starts. Thanks, Hirokazu Takahashi.

...nel. This is impossible because every linux box has various number of disks. So you think it may be possible to make each cgroup have lots of control files for each device as a workaround. But it isn't allowed to add/remove control files when some devices are hot-added or hot-removed. Thanks, Hirokazu Takahashi.

...ere: http://people.valinux.co.jp/~kaizuka/dm-ioband/iobandctl/manual.html You can set up the device with the tool as follows. In this case, you don't need to know the IDs of the cgroups. # iobandctl.py group /dev/mapper/ioband1 cgroup /cgroup/bio/bgroup1:30 /cgroup/bio/bgroup2:60 Thank you, Hirokazu Takahashi.

...ere: http://people.valinux.co.jp/~kaizuka/dm-ioband/iobandctl/manual.html You can set up the device with the tool as follows. In this case, you don't need to know the IDs of the cgroups. # iobandctl.py group /dev/mapper/ioband1 cgroup /cgroup/bio/bgroup1:30 /cgroup/bio/bgroup2:60 Thank you, Hirokazu Takahashi.

Hi everyone, I have a question about cgroup's policy concerning the treatment of threads. Please consider that we want to attach an application which has some threads already to a certain cgroup. If we echo the pid of this application to the "tasks" file connected to this cgroup the threads belonging to this application will NOT be moved to the new group. Is it right? If so, is

Hi everyone, I have a question about cgroup's policy concerning the treatment of threads. Please consider that we want to attach an application which has some threads already to a certain cgroup. If we echo the pid of this application to the "tasks" file connected to this cgroup the threads belonging to this application will NOT be moved to the new group. Is it right? If so, is

Hi all, This is a new release of blkio-cgroup v11. Changes: - The function cgroup_get_from_page() is added which determines to which cgroup a given page belongs. This function is introduced from Vivek's io-controller patch. Thanks Vivek. - Fix a type mismatch of the refcount of io_context. The refcount has been changed to atomic_long_t. This patch can be applied to 2.6.31-rc7. The

Hi all, This is a new release of blkio-cgroup v11. Changes: - The function cgroup_get_from_page() is added which determines to which cgroup a given page belongs. This function is introduced from Vivek's io-controller patch. Thanks Vivek. - Fix a type mismatch of the refcount of io_context. The refcount has been changed to atomic_long_t. This patch can be applied to 2.6.31-rc7. The

Hi all, This is a new release of blkio-cgroup v11. Changes: - The function cgroup_get_from_page() is added which determines to which cgroup a given page belongs. This function is introduced from Vivek's io-controller patch. Thanks Vivek. - Fix a type mismatch of the refcount of io_context. The refcount has been changed to atomic_long_t. This patch can be applied to 2.6.31-rc7. The

Hi all, This is a new release of blkio-cgroup v10. This release reduces IO tracking overhead and fixes an issue that could cause a deadlock since lock_page_cgroup() is no longer used. Thank you KAMEZAWA-san for your suggestions and pointing out the issue. This patch can be applied to 2.6.31-rc3-mmotm0716 and 2.6.31-rc4. The list of the patches: [PATCH 1/7] blkio-cgroup-v10: Introduction

Hi all, This is a new release of blkio-cgroup v10. This release reduces IO tracking overhead and fixes an issue that could cause a deadlock since lock_page_cgroup() is no longer used. Thank you KAMEZAWA-san for your suggestions and pointing out the issue. This patch can be applied to 2.6.31-rc3-mmotm0716 and 2.6.31-rc4. The list of the patches: [PATCH 1/7] blkio-cgroup-v10: Introduction

Hi all, This is a new release of blkio-cgroup v10. This release reduces IO tracking overhead and fixes an issue that could cause a deadlock since lock_page_cgroup() is no longer used. Thank you KAMEZAWA-san for your suggestions and pointing out the issue. This patch can be applied to 2.6.31-rc3-mmotm0716 and 2.6.31-rc4. The list of the patches: [PATCH 1/7] blkio-cgroup-v10: Introduction

Hi everyone, This series of patches of dm-ioband now includes "The bio tracking mechanism," which has been posted individually to this mailing list. This makes it easy for anybody to control the I/O bandwidth even when the I/O is one of delayed-write requests. Have fun! This series of patches consists of two parts: 1. dm-ioband Dm-ioband is an I/O bandwidth controller implemented