FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Redhat > Fedora Development

 
 
LinkBack Thread Tools
 
Old 07-20-2011, 07:20 PM
Jason Baron
 
Default new cg-manager gui tool for managin cgroups

Hi,

I've been working on a new gui tool for managing and monitoring cgroups, called
'cg-manager'. I'm hoping to get people interested in contributing to this
project, as well as to add to the conversation about how cgroups should
be configured and incorporated into distros.

* Intro

I've created a Fedora hosted page for the project, including a screen shot at:

https://fedorahosted.org/cg-manager/

To build and run, it's:

$ git clone git://git.fedorahosted.org/cg-manager.git
$ make
$ sudo ./cg-gui

I've also setup a mailing list to discuss the gui at:

https://fedorahosted.org/mailman/listinfo/cg-manager-developers

Currently, I assume the root user, but I hope to relax that assumption in
future versions. The program is still quite rough, but its been fairly stable
for me. Its a GTK 2.0 based application, written in C (to interface with
libcgroup as much as possible).

* Brief summary of current functionality:

There are two top-level panes (which can be switched b/w using toggle buttons).
The first one centers around cgroup controllers, and the second one is about
configuring cgroup rules.

The memory and cpu share controllers are currently supported (I simply haven't
gotten to supporting other controllers yet). One can add/delete cgroups, change
configuration parameters, and see which processes are currently associated
with each cgroup. There is also a 'usage' view, which displays graphically the
real-time usage statistics. The cgroup configuration can then be saved
into /etc/cgconfig.conf using the 'save' menubar button.

The rules view allows for the creation of rules, such as this process for this
user goes into this cgroup. One can view rules by user and by process name. One
can also save the rules configuration into /etc/cgrules.conf.

I've also introduced the concept of a 'logical' cgroup, which is incorporated
into the cgroup pane and the rules pane. Basically, it allows you to group at
most one cgroup from each hierarchy into a logical group. And then you can
create rules that assign processes to that logical group.

* Future direction:

I've been working Mairin Duffy on what the UI look and feel should eventually
look like...Right now, I have a lot of the elements from Mairin's mockups in
my UI, but its certainly not quite as polished. Mock-ups can be found at:

http://mairin.wordpress.com/2011/05/13/ideas-for-a-cgroups-ui/

* Integration with Fedora/systemd:

Right now, the gui assumes that the various hierarchies are mounted separately,
but that the cpu and cpuacct are co-mounted. Its my understanding that this
is consistent with how systemd is doing things. So that's great.

Currently, the gui saves its state using cgconfig.conf, and cgrules.conf. It
will display what libvirtd and systemd are doing, but will not save the state
for any of the cgroups that are created by libvirt or systemd. So, it
basically ignores these directories as far as persistent configuration. Thus,
it should not conflict with what systemd or libvirtd are doing.

However, I think we need to discuss how we envision cgroup configuration
working longer term. The current consumers out of the box, that I'm aware of
are libvirt and systemd. Currently, these consumers manage cgroups as they see
fit. However, since they are managing shared resources, I think there probably
is an argument to be made that its useful, to have some sort of global view
of things, to understand how resources are being allocated, and thus a global
way of configuring cgroups (as opposed to each new consumer doing its own
thing).

Thus, various privaleged consumers could make 'configuration requests' to a
common API, basically asking what's my configuration data. If there is already
data the consumer can proceed assigning tasks to those cgroups. Otherwise, it
can create a new request, which may or may not be allowed based upon the
available resources on the system. And each consumer can handle what it wants
to do in this case, which could potentially include tweaking the global
configuration.

So for example, in the case of systemd, it continues to have the default
configuration that it currently has, but if the user has gone in and tweaked
the global configuration, that configuration may be re-assigned once we're far
enough along in the boot process to read what that configuration is.

Thanks,

-Jason

--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 07-20-2011, 08:28 PM
Lennart Poettering
 
Default new cg-manager gui tool for managin cgroups

On Wed, 20.07.11 15:20, Jason Baron (jbaron@redhat.com) wrote:

Heya,

> The memory and cpu share controllers are currently supported (I simply haven't
> gotten to supporting other controllers yet). One can add/delete cgroups, change
> configuration parameters, and see which processes are currently associated
> with each cgroup. There is also a 'usage' view, which displays graphically the
> real-time usage statistics. The cgroup configuration can then be saved
> into /etc/cgconfig.conf using the 'save' menubar button.

How does it write that file? Does the UI run as root? That's not really
desirable. It's not secure and it is cumbersome to mix applications
running as differnt users on the same session and one the same X
screen (since they cannot communicate with dbus, and so on).

> Right now, the gui assumes that the various hierarchies are mounted separately,
> but that the cpu and cpuacct are co-mounted. Its my understanding that this
> is consistent with how systemd is doing things. So that's great.

In F15 we mount all controllers enabled in the kernel separately. In F16
we'll optionally mount some of them together, and we'll probably ship a
default of mounting cpu and cpuacct together if they are both enabled.

> Currently, the gui saves its state using cgconfig.conf, and cgrules.conf. It
> will display what libvirtd and systemd are doing, but will not save the state
> for any of the cgroups that are created by libvirt or systemd. So, it
> basically ignores these directories as far as persistent configuration. Thus,
> it should not conflict with what systemd or libvirtd are doing.

Quite frankly, I think cgrulesd is a really bad idea, since it applies
control group limits after a process is already running. This is
necessarily racy (and adds quite a burden too, since you ask for
notifications on each exec()). I'd claim that cgrulesd is broken by
design and cannot be fixed.

> Thus, various privaleged consumers could make 'configuration requests' to a
> common API, basically asking what's my configuration data. If there is already
> data the consumer can proceed assigning tasks to those cgroups. Otherwise, it
> can create a new request, which may or may not be allowed based upon the
> available resources on the system. And each consumer can handle what it wants
> to do in this case, which could potentially include tweaking the global
> configuration.

systemd is the first process of the OS after the initrd finished. At
that time no other process is running, and that means it is not
practical to have systemd talk to any other daemon to get the most basic
of its functionality working.

systemd is and will always have to maintain its own hierarchy
independently of everybody else.

In fact I think running som arbitration daemon which clients talk to to
get a group created is a bad idea anyway: this makes things needless
complex and fragile. If the main reason to do such a thing is to get
events when the cgroup configuration changes then I'd much rather see
changes made to the kernel so that we can get notifications when groups
are created or removed. That could be done via netlink. Another option
would be to hook cgroupfs up with fanotify.

One of the nicer things of cgroups is that an "mkdir" is sufficient to
create a group and an "echo $PID > $GROUP/tasks" to add a process to
it. If you add complex systems on top of that which you need to talk to
instead of trivial "mkdirs" and "open()+write()" you make cgroups much
less attractive.

Lennart

--
Lennart Poettering - Red Hat, Inc.
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 07-20-2011, 08:38 PM
Daniel J Walsh
 
Default new cg-manager gui tool for managin cgroups

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 07/20/2011 03:20 PM, Jason Baron wrote:
> Hi,
>
> I've been working on a new gui tool for managing and monitoring
> cgroups, called 'cg-manager'. I'm hoping to get people interested in
> contributing to this project, as well as to add to the conversation
> about how cgroups should be configured and incorporated into
> distros.
>
> * Intro
>
> I've created a Fedora hosted page for the project, including a screen
> shot at:
>
> https://fedorahosted.org/cg-manager/
>
> To build and run, it's:
>
> $ git clone git://git.fedorahosted.org/cg-manager.git $ make $ sudo
> ./cg-gui
>
> I've also setup a mailing list to discuss the gui at:
>
> https://fedorahosted.org/mailman/listinfo/cg-manager-developers
>
> Currently, I assume the root user, but I hope to relax that
> assumption in future versions. The program is still quite rough, but
> its been fairly stable for me. Its a GTK 2.0 based application,
> written in C (to interface with libcgroup as much as possible).
>
> * Brief summary of current functionality:
>
> There are two top-level panes (which can be switched b/w using toggle
> buttons). The first one centers around cgroup controllers, and the
> second one is about configuring cgroup rules.
>
> The memory and cpu share controllers are currently supported (I
> simply haven't gotten to supporting other controllers yet). One can
> add/delete cgroups, change configuration parameters, and see which
> processes are currently associated with each cgroup. There is also a
> 'usage' view, which displays graphically the real-time usage
> statistics. The cgroup configuration can then be saved into
> /etc/cgconfig.conf using the 'save' menubar button.
>
> The rules view allows for the creation of rules, such as this process
> for this user goes into this cgroup. One can view rules by user and
> by process name. One can also save the rules configuration into
> /etc/cgrules.conf.
>
> I've also introduced the concept of a 'logical' cgroup, which is
> incorporated into the cgroup pane and the rules pane. Basically, it
> allows you to group at most one cgroup from each hierarchy into a
> logical group. And then you can create rules that assign processes to
> that logical group.
>
> * Future direction:
>
> I've been working Mairin Duffy on what the UI look and feel should
> eventually look like...Right now, I have a lot of the elements from
> Mairin's mockups in my UI, but its certainly not quite as polished.
> Mock-ups can be found at:
>
> http://mairin.wordpress.com/2011/05/13/ideas-for-a-cgroups-ui/
>
> * Integration with Fedora/systemd:
>
> Right now, the gui assumes that the various hierarchies are mounted
> separately, but that the cpu and cpuacct are co-mounted. Its my
> understanding that this is consistent with how systemd is doing
> things. So that's great.
>
> Currently, the gui saves its state using cgconfig.conf, and
> cgrules.conf. It will display what libvirtd and systemd are doing,
> but will not save the state for any of the cgroups that are created
> by libvirt or systemd. So, it basically ignores these directories as
> far as persistent configuration. Thus, it should not conflict with
> what systemd or libvirtd are doing.
>
> However, I think we need to discuss how we envision cgroup
> configuration working longer term. The current consumers out of the
> box, that I'm aware of are libvirt and systemd. Currently, these
> consumers manage cgroups as they see fit. However, since they are
> managing shared resources, I think there probably is an argument to
> be made that its useful, to have some sort of global view of things,
> to understand how resources are being allocated, and thus a global
> way of configuring cgroups (as opposed to each new consumer doing its
> own thing).
>
> Thus, various privaleged consumers could make 'configuration
> requests' to a common API, basically asking what's my configuration
> data. If there is already data the consumer can proceed assigning
> tasks to those cgroups. Otherwise, it can create a new request, which
> may or may not be allowed based upon the available resources on the
> system. And each consumer can handle what it wants to do in this
> case, which could potentially include tweaking the global
> configuration.
>
> So for example, in the case of systemd, it continues to have the
> default configuration that it currently has, but if the user has gone
> in and tweaked the global configuration, that configuration may be
> re-assigned once we're far enough along in the boot process to read
> what that configuration is.
>
> Thanks,
>
> -Jason
>

Split the gui in 2. A Priv part (DBUS auto started service) and a non
priv part. X should not run as root. Then use DBUS for communications
between the GUI and the server.


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk4nPMUACgkQrlYvE4MpobNdvgCePZ3eGB1oEX VMzoQ2k+k0W7cY
yGIAoLa2to5BFfMWh8U1Iq4LQHB/YMXT
=hs/8
-----END PGP SIGNATURE-----
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 07-20-2011, 08:42 PM
Vivek Goyal
 
Default new cg-manager gui tool for managin cgroups

On Wed, Jul 20, 2011 at 10:28:32PM +0200, Lennart Poettering wrote:

[..]
>
> > Right now, the gui assumes that the various hierarchies are mounted separately,
> > but that the cpu and cpuacct are co-mounted. Its my understanding that this
> > is consistent with how systemd is doing things. So that's great.
>
> In F15 we mount all controllers enabled in the kernel separately. In F16
> we'll optionally mount some of them together, and we'll probably ship a
> default of mounting cpu and cpuacct together if they are both enabled.

Last time we talked about possibility of co-mounting memory and IO at some
point of time and you said it is a bad idea from applications programming
point of view. Has that changed now?

Thanks
Vivek
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 07-20-2011, 08:59 PM
Vivek Goyal
 
Default new cg-manager gui tool for managin cgroups

On Wed, Jul 20, 2011 at 10:28:32PM +0200, Lennart Poettering wrote:

[..]
> systemd is and will always have to maintain its own hierarchy
> independently of everybody else.

In the presentation today, you mentioned that you would like to create
cgroups for users by default in cpu hierarchy (once RT time allocation
issue is resolved). I am wondering what happens if an admin wants to
change the policy a bit. Say give higher cpu shares to a specific
user.

Generally one should have been able to do this with the help of GUI
tool. Show the system view and allow to change the parameters (which
are persistent across reboot).

How is one supposed to do that. As it looks like that part of the
control lies with systemd (as it is the one creates user group under
cpu) and part of the control lies with GUItool/cgconfig.

Thanks
Vivek
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 07-20-2011, 09:07 PM
Lennart Poettering
 
Default new cg-manager gui tool for managin cgroups

On Wed, 20.07.11 16:42, Vivek Goyal (vgoyal@redhat.com) wrote:

>
> On Wed, Jul 20, 2011 at 10:28:32PM +0200, Lennart Poettering wrote:
>
> [..]
> >
> > > Right now, the gui assumes that the various hierarchies are mounted separately,
> > > but that the cpu and cpuacct are co-mounted. Its my understanding that this
> > > is consistent with how systemd is doing things. So that's great.
> >
> > In F15 we mount all controllers enabled in the kernel separately. In F16
> > we'll optionally mount some of them together, and we'll probably ship a
> > default of mounting cpu and cpuacct together if they are both enabled.
>
> Last time we talked about possibility of co-mounting memory and IO at some
> point of time and you said it is a bad idea from applications programming
> point of view. Has that changed now?

Well, no, but yes.

After discussing this Dhaval the scheme we came up with is to add
symlinks to /sys/fs/cgroup/ so that even when some controllers are
mounted together they are still available at the the separate
directories. Example, if we mount cpu+cpuacct together things will look
like this:

/sys/fs/cgroup/cpu+cpuacct is the joint mount point.

/sys/fs/cgroup/cpu → /sys/fs/cgroup/cpu+cpuacct is a symlink.

/sys/fs/cgroup/cpuacct → /sys/fs/cgroup/cpu+cpuacct is a symlink.

That way to most applications it will be very easy to support this: they
can simply assume that the controller "foobar" is available under
/sys/fs/cgroup/foobar, and that's it.

Lennart

--
Lennart Poettering - Red Hat, Inc.
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 07-20-2011, 09:11 PM
Lennart Poettering
 
Default new cg-manager gui tool for managin cgroups

On Wed, 20.07.11 16:59, Vivek Goyal (vgoyal@redhat.com) wrote:

>
> On Wed, Jul 20, 2011 at 10:28:32PM +0200, Lennart Poettering wrote:
>
> [..]
> > systemd is and will always have to maintain its own hierarchy
> > independently of everybody else.
>
> In the presentation today, you mentioned that you would like to create
> cgroups for users by default in cpu hierarchy (once RT time allocation
> issue is resolved). I am wondering what happens if an admin wants to
> change the policy a bit. Say give higher cpu shares to a specific
> user.

He can just go and do that. systemd assume to be the exclusive owner of
/sys/fs/cgroup/systemd, but the other hierarchies can be manipulated by
others too. That means that if people want to create a hierarchy there,
then they can do that. If people want systemd to stop mucking with the
cpu hierarchy for all users then this can be configured in a simple
config file.

> How is one supposed to do that. As it looks like that part of the
> control lies with systemd (as it is the one creates user group under
> cpu) and part of the control lies with GUItool/cgconfig.

Right now, systemd has few controls to actually make use of
controllers. It assumes that the limits on hte controllers are already
configured by something else.

Lennart

--
Lennart Poettering - Red Hat, Inc.
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 07-20-2011, 09:26 PM
Vivek Goyal
 
Default new cg-manager gui tool for managin cgroups

On Wed, Jul 20, 2011 at 11:07:14PM +0200, Lennart Poettering wrote:
> On Wed, 20.07.11 16:42, Vivek Goyal (vgoyal@redhat.com) wrote:
>
> >
> > On Wed, Jul 20, 2011 at 10:28:32PM +0200, Lennart Poettering wrote:
> >
> > [..]
> > >
> > > > Right now, the gui assumes that the various hierarchies are mounted separately,
> > > > but that the cpu and cpuacct are co-mounted. Its my understanding that this
> > > > is consistent with how systemd is doing things. So that's great.
> > >
> > > In F15 we mount all controllers enabled in the kernel separately. In F16
> > > we'll optionally mount some of them together, and we'll probably ship a
> > > default of mounting cpu and cpuacct together if they are both enabled.
> >
> > Last time we talked about possibility of co-mounting memory and IO at some
> > point of time and you said it is a bad idea from applications programming
> > point of view. Has that changed now?
>
> Well, no, but yes.
>
> After discussing this Dhaval the scheme we came up with is to add
> symlinks to /sys/fs/cgroup/ so that even when some controllers are
> mounted together they are still available at the the separate
> directories. Example, if we mount cpu+cpuacct together things will look
> like this:
>
> /sys/fs/cgroup/cpu+cpuacct is the joint mount point.
>
> /sys/fs/cgroup/cpu → /sys/fs/cgroup/cpu+cpuacct is a symlink.
>
> /sys/fs/cgroup/cpuacct → /sys/fs/cgroup/cpu+cpuacct is a symlink.
>
> That way to most applications it will be very easy to support this: they
> can simply assume that the controller "foobar" is available under
> /sys/fs/cgroup/foobar, and that's it.

I guess this will be reasonable. Just that application need to handle
the case that directory they are about to create might already be present
there.

So down the we should be able to co-mount memory and IO together with
additional symlinks?

Thanks
Vivek
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 

Thread Tools




All times are GMT. The time now is 06:15 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org