Hi, Andrea.
I participated in Containers Mini-summit.
And, I talked with Mr. Andrew Morton in The Linux Foundation Japan
Symposium BoF, Japan, July 10th.
Currently, in ML, some I/O controller patches is sent and the respective
patch keeps sending the improvement version.
We and maintainers wouldn't like this situation.
We wanted to solve this situation by the Mini-summit, but unfortunately,
no other developers participated.
(I couldn't give an opinion, because my English skill is low)
Mr. Naveen present his way in Linux Symposium, and we discussed about
I/O control at a few time after this presentation.
Mr. Andrew gave a advice "Should discuss about design more and more"
to me.
And, in Containers Mini-summit (and Linux Symposium 2008 in Ottawa),
Paul said that a necessary to us is to decide a requirement first.
So, we must discuss requirement and design.
My requirement is
* to be able to distribute performance moderately.
(* to be able to isolate each group(environment)).
I guess (it may be wrong)
Naveen's requirement is
* to be able to handle latency.
(high priority is always precede in handling I/O)
(Only share isn't just given priority to, like CFQ.)
* to be able to distribute performance moderately.
Andrea's requirement is
* to be able to set and control by absolute(direct) performance.
Ryo's requirement is
* to be able to distribute performance moderately.
* to be able to set and control I/Os at flexible range
(multi device such as LVM).
I think that most solutions controls I/O performance moderately
(by using weight/priority/percentage/etc. and by not using absolute)
because disk I/O performance is inconstant and is affected by
situation (such as application, file(data) balance, and so on).
So, it is difficult to guarantee performance which is set by
absolute bandwidth.
If devices have constant performance, it will good to control by
absolute bandwidth.
And, when guaranteeing it by the low ability, it'll be possible.
However, no one likes to make the resources wasteful.
And, he gave a advice "Can't a framework which organized each way,
such as I/O elevator, be made?".
I try to consider such framework (in elevator layer or block layer).
Now, I look at the other methods, again.
I think that OOM problems caused by memory/cache systems.
So, it will be better that I/O controller created out of these problems
first, although a lateness of the I/O device would be related.
If these problem can be resolved, its technique should be applied into
normal I/O control as well as cgroups.
Buffered write I/O is also related with cache system.
We must consider this problem as I/O control.
I don't have a good way which can resolve this problems.
I'm very interested in this results.
Thanks,
Satoshi Uchida.
--
