On Mon 05-03-12 17:18:43, Vivek Goyal wrote: > On Mon, Mar 05, 2012 at 09:23:30PM +0100, Jan Kara wrote: > > [..] > > Having the limits for dirty rate and other IO separate means I > > have to be rather pesimistic in setting the bounds so that combination of > > dirty rate + other IO limit doesn't exceed the desired bound but this is > > usually unnecessarily harsh... > > We had solved this issue in my previous posting. > > https://lkml.org/lkml/2011/6/28/243 > > I was accounting the buffered writes to associated block group in > balance dirty pages and throttling it if group was exceeding upper > limit. This had common limit for all kind of writes (direct + buffered + > sync etc). Ah, I didn't know that. > But it also had its share of issues. > > - Control was per device (not global) and was not applicable to NFS. > - Will not prevent IO spikes at devices (caused by flusher threads). > > Dave Chinner preferred to throttle IO at devices much later. > > I personally think that "dirty rate limit" does not solve all problems > but has some value and it will be interesting to merge any one > implementation and see if it solves a real world problem. It rather works the other way around - you first have to show enough users are interested in the particular feature you want to merge and then the feature can get merged. Once the feature is merged we are stuck supporting it forever so we have to be very cautious in what we merge... > It does not block any other idea of buffered write proportional control > or even implementing upper limit in blkcg. We could put "dirty rate > limit" in memcg and develop rest of the ideas in blkcg, writeback etc. Yes, it doesn't block them but OTOH we should have as few features as possible because otherwise it's a configuration and maintenance nightmare (both from admin and kernel POV). So we should think twice what set of features we choose to satisfy user demand. Honza -- Jan Kara <jack@xxxxxxx> SUSE Labs, CR -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
