Thank you for reply. > > + > > +static struct cgroup_subsys_state * > > +cfq_cgroup_create(struct cgroup_subsys *ss, struct cgroup *cont) > > +{ > > + struct cfq_cgroup *cfqc; > > + > > + if (!capable(CAP_SYS_ADMIN)) > > + return ERR_PTR(-EPERM); > > + > > + if (!cgroup_is_descendant(cont)) > > + return ERR_PTR(-EPERM); > > What are these checks for? Cgroups already provides filesystem > permissions to control directory creation, and the "descendant" check > looks like it may have been cut/pasted from the nsproxy subsystem. > This code was referred one of io-throttle. Is it not necessary these checks? IF not necessary, remove this code. > > > /* */ > > + > > +#ifdef CONFIG_CGROUP_CFQ > > +SUBSYS(cfq_cgroup) > > +#endif > > + > > +/* */ > > To fit with the convention for other subsystems, simply "cfq" would be > a better name than "cfq_cgroup". (Clearly it's a cgroup subsystem from > context). > Ok, I change name. I hesitated whether using "_cgroup". The cpuset and the cpuacct does not use it, but cpu and memory uses it(cpu_cgroup and mem_cgroup). In this patchset, I select the latter case. > Is this subsystem meant to allow you to control any device that uses > CFQ, or is it specific to disks? It would be nice to be able to allow > different groups have different guarantees on different disks. > I want to allow to control any devices. (Now, any devices using CFQ) However, I think the main target of above device is disk devices. I think so that a different groups have different guarantees on different disks. And, It would be more better to be able to allow different hierarchies for different disks. Now, I consider two solutions. One is that a new resource manager(subsystem) is created when new device is plugged. But, The current cgroup framework would not be resisted dynamically. The another is that a new file entry is resisted when new device is plugged. But, when a new cgroup is created, there are only information that request_queue and cgroup structure. So, I seem that device name cannot be referred. Namely, a name of entry cannot be defined. And, this means cannot have different hierarchies. I try to this mechanism in future. I missed. This patchset is not all. There is not a patch for adding the "ioprio" entry. I resend this patchset after fixing name and checking. Thanks, Satoshi UCHIDA