Messages in this thread | | | Date | Wed, 6 Aug 2008 11:44:25 +0900 | From | KAMEZAWA Hiroyuki <> | Subject | Re: Too many I/O controller patches |
| |
On Tue, 05 Aug 2008 09:20:18 -0700 Dave Hansen <dave@linux.vnet.ibm.com> wrote:
> On Tue, 2008-08-05 at 11:28 +0200, Andrea Righi wrote: > > > Buffered write I/O is also related with cache system. > > > We must consider this problem as I/O control. > > > > Agree. At least, maybe we should consider if an IO controller could be > > a valid solution also for these problems. > > Isn't this one of the core points that we keep going back and forth > over? It seems like people are arguing in circles over this: > > Do we: > 1. control potential memory usage by throttling I/O > or > 2. Throttle I/O when memory is full > > I might lean toward (1) if we didn't already have a memory controller. > But, we have one, and it works. Also, we *already* do (2) in the > kernel, so it would seem to graft well onto existing mechanisms that we > have. > > I/O controllers should not worry about memory. I agree here ;)
>They're going to have a hard enough time getting the I/O part right. :) > memcg have more problems now ;(
Only a difficult thing to limit dirty-ratio in memcg is how-to-count dirty pages. If I/O controller's hook helps, it's good.
My small concern is "What happens if we throttole I/O bandwidth too small under some memcg." In such cgroup, we may see more OOMs because I/O will not finish in time. A system admin have to find some way to avoid this.
But please do I/O control first. Dirty-page control is related but different layer's problem, I think.
Thanks, -Kame
> Or, am I over-simplifying this? >
-- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |