[lkml]   [2008]   [Apr]   [2]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRE: [RFC][patch 3/11][CFQ-cgroup] Introduce cgroup subsystem
    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.

    Satoshi UCHIDA
    [unhandled content-type:application/x-pkcs7-signature]
     \ /
      Last update: 2008-04-03 04:35    [W:0.025 / U:5.696 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site