LKML Archive on
help / color / mirror / Atom feed
From: Balbir Singh <>
To: Xpl++ <>
Cc: Dhaval Giani <>,,,
	lkml <>,,
	Balbir Singh <>,, Peter Zijlstra <>,
	Srivatsa Vaddagiri <>,
	Sudhir Kumar <>
Subject: Re: [RFC] libcg: design and plans
Date: Wed, 05 Mar 2008 10:18:50 +0530	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

Xpl++ wrote:
> Hi,
> I was wonder if creating such library makes any sense at all,
> considering the nature of cgroups, the way they work and their possible
> application?
> It seems to me that any attempt to create a 'simple' API would actualy
> result in something that will be much harder to use that just making raw
> mkdir/open/read/write/close operations. Another thing is suggested
> config for this lib would be more appropriate for a daemon rather than a
> library.

The configuration file is important, since it allows us two levels of control.
At one level the system administrator and at the other level applications. Each
application can maintain it's own hierarchy across reboots.

We thought of a daemon, but there were several overheads and disadvantages. For
one, we needed an IPC mechanism to communicate every client request to the
daemon, the client being the application. The daemon also becomes the single
point of failure for all applications. Moreover, we want to provide the ability
to programmatically update the configuration. A daemon, if desired can be built
on top of the library we propose.

> In general - cgroup is a very flexible subsystem that can be used in a
> wide variety of ways and modes and trying to create a universal simple
> API would more likely result in something hard to manage and work with.

I agree that cgroups is flexible, but why do you think abstracting common tasks
amongst applications will be hard to manage and work with? We want to provide
API that will allow us to fill in parameters and say -- go create this group or
delete this group.

> The idea of having multiple container managers (applications that use
> libcg) creates a lots of questions and possible issues. Containers are
> supposed provide a flexible resource management and task grouping
> ability, which somewhat implies that there cannot be two different
> resource managers per node without one knowing well the
> desires/goals/methods of the other and vice versa.

We don't assume that there cannot be two different resource managers per node.
We don't enforce any policy, we just allow for easy creation and manipulation of
control groups hierarchially.

And should there be
> only one manager per node - probably it will be easier for it to use
> cgroup subsystem directly rather than using a wrapper library?

Could you please elaborate, why is it probably easier?

	Warm Regards,
	Balbir Singh
	Linux Technology Center

  reply	other threads:[~2008-03-05  4:51 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-03-04 15:23 Dhaval Giani
2008-03-04 17:15 ` Xpl++
2008-03-05  4:48   ` Balbir Singh [this message]
2008-03-05  5:26   ` Dhaval Giani
2008-03-05 11:56     ` Xpl++
2008-03-05 15:53       ` Dhaval Giani
2008-03-05 19:36         ` Xpl++
2008-03-04 18:05 ` Dave Hansen
2008-03-05  6:15 ` Paul Menage
2008-03-05  7:17   ` [Devel] " Denis V. Lunev
2008-03-05 11:48     ` Balbir Singh
2008-03-05 10:33   ` Dhaval Giani
2008-03-05 10:41     ` Paul Menage
2008-03-05 11:07       ` Dhaval Giani
2008-03-05 11:51         ` Paul Menage
2008-03-05 14:24           ` Balbir Singh
2008-03-05 18:55             ` Paul Menage
2008-03-20 22:04 ` Rik van Riel

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \ \ \ \ \ \ \ \ \ \
    --subject='Re: [RFC] libcg: design and plans' \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).