linux-kernel - Re: [PATCH 2/2] blk-throttle: Take blkcg->lock while traversing blkcg->policy

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Tue, 25 Oct 2011 16:13:11 +0200
From:	Jens Axboe <jaxboe@...ionio.com>
To:	Vivek Goyal <vgoyal@...hat.com>
CC:	Tejun Heo <tj@...nel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
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

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/