Re: [PATCH 08/17] blkcg: shoot down blkio_groups on elevator switch

[Vivek Goyal]

On Mon, Jan 23, 2012 at 08:16:19AM -0800, Tejun Heo wrote:
> On Mon, Jan 23, 2012 at 11:10:42AM -0500, Vivek Goyal wrote:
> > This does not work well in hierachical management/scenario. Think that
> > a user gets an upper limit of 10MB/s on a device and now user can manage
> > its own children groups and divide allocated 10MB/s in children the way
> > he wants.
> > 
> > Now if root does the elevator switch, and saves all the rules (including
> > user's rules) and then restores back, these can very well race with
> > user's scripts of changing rules. If user changed a cgroup device rule
> > during elevator switch and after elevator switch root restored back
> > old rules, user's new rule will be lost leading to confusion.
> 
> It simply doesn't matter.  Just declare elvswitch and policy change
> reset blkcg configurations.  If some people are crazy enough to switch
> elevators regularly with full system running and parallel
> configuration going on, let them deal with synchronizing their
> scripts.

It does not have to be a regular switch. Even one switch during boot
can create issues. 

In RHEL we have the set of scripts which can do system tuning like based
on user chosen profile (tuned). These scripts do various things including
changing elevator. Once you have chosen the profile, it gets applied
automatically over every boot (through init scripts).

Now assume that after a reboot libvirtd is running and resuming various
suspended virtual machines or starting new one and in parallel this
profile is being applied. There is no way to avoid races as systemd allows
parallel execution of services. The only way left will be strong
serialization and that is no cgroup operation is taking place in the
system while some init script is chaning the elevator (no new cgroup
creatoin, no cgroup deletions and no rule settings by any daemon),
otherwise changes might be lost. In practice how would I program 
various init scripts for this?

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