cgroupstats, plans? - Kernel

This is a discussion on cgroupstats, plans? - Kernel ; Hi Paul, You had mentioned in http://lkml.org/lkml/2008/4/8/29 about cgroup binary API for statistics. What is the status wrt to that? We are looking to export statistics using libcg. One of the questions that comes up is when is a file ...

+ Reply to Thread
Results 1 to 4 of 4

Thread: cgroupstats, plans?

  1. cgroupstats, plans?

    Hi Paul,

    You had mentioned in http://lkml.org/lkml/2008/4/8/29 about cgroup
    binary API for statistics. What is the status wrt to that?

    We are looking to export statistics using libcg. One of the questions
    that comes up is when is a file in the cgroup, a control file (one used
    to control the parameters of the subsystem) and when is it a file which
    is related to statistics. Maybe a binary API might help us there.

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

  2. Re: cgroupstats, plans?

    On Tue, Apr 29, 2008 at 5:20 AM, Dhaval Giani wrote:
    > Hi Paul,
    >
    > You had mentioned in http://lkml.org/lkml/2008/4/8/29 about cgroup
    > binary API for statistics. What is the status wrt to that?


    I've not really had mmore time to work on that since then.

    Assuming people are happy with the basic ideas in that post then I
    guess the important questions to focus on would be:

    - what form should the API description to userspace take? Something
    like the cgroup.api file that I proposed a while ago?

    - how would the user specify and retrieve a specific set of stats?
    should we just dump all stats on each read request, or will that be
    too expensive for some stats?

    >
    > We are looking to export statistics using libcg. One of the questions
    > that comes up is when is a file in the cgroup, a control file (one used
    > to control the parameters of the subsystem) and when is it a file which
    > is related to statistics.


    I don't see why some of them can't be both. If a file has a numerical
    value associated with it, is there any reason not to make it available
    via the binary stats API, regardless of whether that value was
    generated by userspace or the kernel?

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

  3. Re: [Libcg-devel] cgroupstats, plans?

    Paul Menage wrote:
    > On Tue, Apr 29, 2008 at 5:20 AM, Dhaval Giani wrote:
    >> Hi Paul,
    >>
    >> You had mentioned in http://lkml.org/lkml/2008/4/8/29 about cgroup
    >> binary API for statistics. What is the status wrt to that?

    >
    > I've not really had mmore time to work on that since then.
    >
    > Assuming people are happy with the basic ideas in that post then I
    > guess the important questions to focus on would be:
    >
    > - what form should the API description to userspace take? Something
    > like the cgroup.api file that I proposed a while ago?
    >
    > - how would the user specify and retrieve a specific set of stats?
    > should we just dump all stats on each read request, or will that be
    > too expensive for some stats?
    >


    I would prefer to select the controller from user stats and then dump the stats
    from the kernel for that controller using cgroupstats.

    >> We are looking to export statistics using libcg. One of the questions
    >> that comes up is when is a file in the cgroup, a control file (one used
    >> to control the parameters of the subsystem) and when is it a file which
    >> is related to statistics.

    >
    > I don't see why some of them can't be both. If a file has a numerical
    > value associated with it, is there any reason not to make it available
    > via the binary stats API, regardless of whether that value was
    > generated by userspace or the kernel?
    >


    I agree. I think we need to start pushing the statistics so that we can have a
    good set of statistics. I am going to try and do some cgroupstats work and
    publish it soon.

    --
    Warm Regards,
    Balbir Singh
    Linux Technology Center
    IBM, ISTL
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  4. Re: [Libcg-devel] cgroupstats, plans?

    On Fri, May 2, 2008 at 2:14 AM, Balbir Singh wrote:
    >
    > I would prefer to select the controller from user stats and then dump the stats
    > from the kernel for that controller using cgroupstats.
    >


    Yes, that's fine if you're not worried about the cost of some stats
    being excessive. I'm not sure whether that's going to be the case or
    not. What about those control files that are of type string? Do we
    want to return them as stats?

    If we're going to use the cgroupstats API, I think we should avoid
    having to have each controller have to publish a binary API - we have
    the name->type information already in the control file structures.

    So how about something like this as the hard-coded part of the API?
    (probably needs to be tidied up to fit into the taskstats format)

    a new command CGROUP_STATS_GET_API which returns a sequence of
    structures of the form:

    struct cgroup_stat_subsys {
    u32 reclen;
    u32 id;
    u32 numstats;
    char name[];
    };

    enum {
    CGROUP_STAT_TYPE_U64,
    CGROUP_STAT_TYPE_S64,
    CGROUP_STAT_TYPE_STRING, /* maybe */
    CGROUP_STAT_TYPE_U64MAP,
    };

    struct cgroup_stat_type {
    u32 reclen;
    u32 id;
    u32 type;
    char name[];
    };

    When the user sends a CGROUP_STATS_GET_API request they get a sequence
    of cgroup_stat_subsys records (one for each subsystem on that
    hierarchy), each followed by the stats available for that subsystem.
    E.g.

    { 0, 3, "memory" }
    { 0, CGROUP_STAT_TYPE_U64, "usage_in_bytes" }
    { 1, CGROUP_STAT_TYPE_U64, "limit_in_bytes" }
    { 2, CGROUP_STAT_TYPE_U64MAP, "stat" }
    { 1, 1, "cpuacct" }
    { 0, CGROUP_STAT_TYPE_U64, "usage" }

    a new command CGROUP_SET_STATS_REQUEST that lets you tie a particular
    set of stats to a given socket. E.g. the parameter structure could be
    something like a sequence of records of the form:

    struct cgroup_stats_request {
    u32 subsys_id;
    u32 stat_id;
    }

    Following a successful CGROUP_SET_STATS_REQUEST command, the user
    could send a CGROUP_DUMP_STATS command on the same socket to get a
    dump of the requested stats in the specified order.

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

+ Reply to Thread