RE: [RFC][patch 3/11][CFQ-cgroup] Introduce cgroup subsystem

["Satoshi UCHIDA" <s-uchida@ap.jp.nec.com>]

[-- Attachment #1: Type: text/plain, Size: 2420 bytes --]

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

[-- Attachment #2: smime.p7s --]
[-- Type: application/x-pkcs7-signature, Size: 4961 bytes --]