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

From: Satoshi UCHIDA
Date: Wed Apr 02 2008 - 22:32:16 EST


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: smime.p7s
Description: S/MIME cryptographic signature