cgroupstats, plans?

cgroupstats, plans?

[Dhaval Giani]

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

Re: cgroupstats, plans?

[Paul Menage]

On Tue, Apr 29, 2008 at 5:20 AM, Dhaval Giani <dhaval@linux.vnet.ibm.com> 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

Re: [Libcg-devel] cgroupstats, plans?

[Balbir Singh]

Paul Menage wrote:
> On Tue, Apr 29, 2008 at 5:20 AM, Dhaval Giani <dhaval@linux.vnet.ibm.com> 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

Re: [Libcg-devel] cgroupstats, plans?

[Paul Menage]

On Fri, May 2, 2008 at 2:14 AM, Balbir Singh <balbir@linux.vnet.ibm.com> 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