| |||||||||||||
why not stack themwhy not stack themPosted May 13, 2009 0:28 UTC (Wed) by pflugstad (subscriber, #224)Parent article: Which I/O controller is the fairest of them all? While I agree that putting the I/O controller at the existing I/O schedule layer seems to make the most sense, I would have thought that an obvious solution to this type of thing would be to modify the block layer setup so that you can stack I/O controllers and schedulers. Instead of integrating io-controller into each I/O scheduler as what seems to be being done here (please correct me of I'm mistaken). That way, you can possibly select a different io controller and io scheduler combo and you don't have all the code churn if you want yet another io controller algorithm.
(Log in to post comments)
why not stack them Posted May 13, 2009 1:28 UTC (Wed) by vgoyal (subscriber, #49279) [Link]
I personally think that IO controller is basically an IO scheduling operation. CFQ already provides fairness between processes. IO controller extends the same concept to provide fairness between process groups also.
Now if fairness between processes and fairness among process groups is implemented at two different places then we run into the issue of one not knowing about the policy of other and higher level process group fairness breaking the notion of lower level IO scheduler. For example, higher level controller would not know anything about process classes (RT, BE, IDLE) or prorities with-in classes, or how reads are favored over writes etc by the IO scheduler etc.
I draw parallel from cpu controller where process group scheduling is implemented along with process scheduling in the group. They are not different entities stacked on top of each other.
So stacking one on top of other probably is not the best idea. Implementing it at elevator layer enables us to implement in such a manner so that code sharing can take place between 4 IO schedulers and code duplication is avoided.
The only limitation of doing it at IO scheduler level is that we provide hierarhical IO scheduling only at leaf nodes where IO scheduler is running and not at intermediate higher level logical devices. This is inline with IO scheduling status as of today where notion of process io priority or classes is only in effect on leaf nodes and not on intermediate logical devices.
If we really need control at higher level logical devices (which I am not very sure about), then we need to come up with something better. One suggestion was to update the weights of individual groups on end devices dynamically (I think it is hard to implement). Or may be we need a higher level controller also which breaks the underlying IO controller but provides fairness among group?
I personally think that by implementing hierarchical control at IO scheduler level we get at least one thing right and may be cover majority of the cases. At least we should get that right first.
|
|||||||||||||