Hi, > > > > 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. I/O controllers are just supposed to emulate slow device from the point of view of the processes in a certain cgroup or something. I think the memory management layer and the memory controller are the ones which should be able to handle these, which might be as slow as floppy disks though. > 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. Yup. Thanks, Hirokazu Takahashi. -- dm-devel mailing list dm-devel@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/dm-devel
