linux-kernel - Re: [Libcg-devel] cgroupstats, plans?

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <6599ad830805122310q2f403745kd114ec11a8e51b1d@mail.gmail.com>
Date:	Mon, 12 May 2008 23:10:48 -0700
From:	"Paul Menage" <menage@...gle.com>
To:	balbir@...ux.vnet.ibm.com
Cc:	"Dhaval Giani" <dhaval@...ux.vnet.ibm.com>, vivk@...ibm.com,
	"Peter Zijlstra" <a.p.zijlstra@...llo.nl>,
	"Balbir Singh" <balbir@...ibm.com>,
	"Srivatsa Vaddagiri" <vatsa@...ux.vnet.ibm.com>,
	lkml <linux-kernel@...r.kernel.org>,
	libcg-devel <libcg-devel@...ts.sourceforge.net>,
	"Balaji Rao" <balajirrao@...il.com>
Subject: Re: [Libcg-devel] cgroupstats, plans?

On Fri, May 2, 2008 at 2:14 AM, Balbir Singh <balbir@...ux.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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/