Jens Axboe wrote: > Your approach is totally flawed, imho. For instance, you don't want a > process to be able to dirty memory at foo mb/sec but only actually > write them out at bar mb/sec.
Right. Actually my problem here is that the processes that write out blocks are different respect to the processes that write bytes in memory, and I would be able to add limits on those processes that are dirtying memory. > The noop-iosched changes are also very buggy. The queue back pointer > breaks reference counting and the task pointer storage assumes the task > will also always be around. That's of course not the case. Yes, this really need a lot of fixes. I simply posted the patch to know if such approach (in general) could have sense or not. > IOW, you are doing this at the wrong level. > > What problem are you trying to solve? Limiting block I/O bandwidth for tasks that belong to a generic cgroup, in order to provide a sort of a QoS on block I/O. Anyway, I'm quite new in the wonderful land of the I/O scheduling, so any help is appreciated. Thanks, -Andrea -- 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/
