Hirokazu Takahashi wrote:
i/o controller: This controller is not ported to the framework posted,
but can be taken for a prototype version. New version would be simpler
though.
I think controlling I/O bandwidth is right way to go.
Thanks. Obviously we agree heartily :-)
However, I think you need to change the design of the controller a bit.
A lot of I/O requests processes issue will be handled by other contexts.
There are AIO, journaling, pdflush and vmscan, which some kernel threads
treat instead of the processes.
The current design looks not to care about this.
Yes. The current design, which builds directly on top of the CFQ
scheduler, does not attempt to treat kernel
threads specially in order to account the I/O they're doing on behalf of
others properly. This was mainly because
of the desire to keep the controller simple.
I suspect pdflush and vmscan I/O is never going to be properly
attributable and journaling may be possible but
unlikely to be worth it given the risks of throttling it ? AIO is
likely to be something we can address if there is
consensus that one is willing to pay the price of tracking the source
through the I/O submission layers.
I suppose this would be a good time to dust off the I/O controller and
post it so discussions can become more
concrete.
But as always, changes in the design and implementation are always
welcome....
Regards,
Shailabh
Thanks,
Hirokazu Takahashi.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
