Messages in this thread | | | Date | Tue, 25 Oct 2011 16:13:11 +0200 | From | Jens Axboe <> | Subject | Re: [PATCH 2/2] blk-throttle: Take blkcg->lock while traversing blkcg->policy_list |
| |
On 2011-10-21 14:10, Vivek Goyal wrote: > On Thu, Oct 20, 2011 at 02:29:58PM -0700, Tejun Heo wrote: >> Hello, >> >> On Thu, Oct 20, 2011 at 05:20:21PM -0400, Vivek Goyal wrote: >>> The only problem with this approach is that it will cleanup per device >>> weight rules also at elevator_exit() time which is not same as device >>> removal and one might device to bring CFQ back on device and we will >>> need the rules again. >> >> I actually think removoing those rules on elevator detach would be the >> right thing to do. We don't try to keep cfq setting across elevator >> switch. When we're switching from cfq, we're detaching iocg policy >> too. The settings going away is perfectly fine. I actually think >> it's a pretty bad idea to implement ad-hoc setting persistence in >> kernel. Just making sure that userland is notified is far better >> approach. Userland has all the facilities to deal with this type of >> situations. >> >> When switching from cfq to deadline, we lose the whole proportional io >> control. It's way more confusing to have lingering settings which >> don't do anything. > > I am not so sure about this. Suppose tomorrow another IO sheduler starts > taking into account the cgroup gloabl weight or cgroup per device weight > to do some kind of IO prioritization, then removing the rules upon > changing the IO schduler will not make sense. > > IOW, rules are per cgroup per device and not per cgroup per IO scheduler > and more than one IO scheduler should be able to share the rules.
FWIW, I agree with Tejun here. A switch operation is a reset, start from scratch. We don't preserve other per IO-scheduler settings on a switch, preserving _some_ settings is just confusing.
-- Jens Axboe
| |