cgroupを使う時のメモ1 - コンピュータ技術者になるための備忘録

間違っているところがあると思うので注意
どのディストリビューションでも使えると思うけどこの記事はgentooを前提に書いてます

そもそもcgroupとはなんぞや?

説明できるほど理解できているとは思えないけど
cgroupとはコントロールグループと呼ばれる機能でこれによりコンピュータの資源をグループ単位で割り当てることができるようになる
これによりコンピュータの効率の向上が期待できるらしい
詳しくは
https://docs.redhat.com/docs/ja-JP/Red_Hat_Enterprise_Linux/6/html/Resource_Management_Guide/ch01.html
これ見たほうが早いです。ここに書いてあるのを短くまとめてみただけです

どうやったら使えるの?

まずlinux カーネルが対応していなければ使うことができません
http://insnvlovn.blogspot.jp/2011/06/configschedautogroup.html
こちらのサイトを参考にして

% cat /proc/sys/kernel/sched_autogroup_enabled
1

として1が返ってきたら有効になっているのでカーネル再構築をする必要はありませんが
有効になっていない場合は予めlinux カーネルのソースを用意して

gentooだとこんな感じ
# emerge -va "sys-kernel/gentoo-sources"

ソースのあるディレクトリに移動します

$ cd /usr/src/linu

カーネルのオプション画面を出します

# make menuconfig

Automatic process group schedulingを有効にします

General setup --->
Automatic process group scheduling

にあります
スペースなどを使って[*]に変えて有効にしたら保存して閉じます
後はいつも通りカーネルを再構築するだけです

# make bzImage

こんな感じでできますが私はいつも

time sudo nice -n 19 sh -c 'CCACHE_DIR="/var/tmp/ccache" make bzImage -j2 CC="ccache gcc" HOSTCC="ccache gcc" HOSTCXX="ccache g++"'

とやってccacheを有効にしてやってます
再構築が終われば

# cp arch/i386/boot/bzImage /boot/linux-3.2.12-gentoo

などをしてブートローダが読み込むファイルに置き換えます
後は再起動をして

% cat /proc/sys/kernel/sched_autogroup_enabled
1

1が返ってくれば有効になってます
次にcgroupを簡単に使うためにlibcgroupを使います
gentooを使っている方は

# emerge -va "dev-libs/libcgroup"

これで入ります
もし自分の使っているパッケージ管理にない場合は
http://sourceforge.net/projects/libcg/
ここからソースコードをダウンロードできるので各自で入れてください
これで前準備は整いました

実際に使えるように設定をする

https://docs.redhat.com/docs/ja-JP/Red_Hat_Enterprise_Linux/6/html/Resource_Management_Guide/ch-Using_Control_Groups.html
ここが詳しいです
emergeで入れた場合は設定ファイルは

/etc/cgroup/cgconfig.conf
と
/etc/cgroup/cgrules.conf

にあるみたいです
それぞれmanが用意されているみたいなのでちゃんと導入している人は

man cgconfig.conf
や
man cgrules.conf

などで見れます
manを見るとデフォルトだと設定ファイルは

/etc/cgconfig.conf
と
/etc/cgrules.conf

にあるみたいです

それでは早速cgconfig.confをいじりたいのですがどういじればいいのかわからないので
まずはman cgconfig.confを読みます。日本語訳はないので英語を読みましょう
私の訳が合っている保証はないので注意

間に挟んで追記:
訳は以下にまとめて置いときます
一部変な訳がありますがそれでもいい人はどうぞ
man cgconfig.conf
https://gist.github.com/3076435

man cgrules.conf
https://gist.github.com/3076472

原文:
NAME
       cgconfig.conf - libcgroup configuration file

DESCRIPTION
       cgconfig.conf  is  the  configuration  file used by libcgroup to define control groups,
       their parameters and also mount points.  The file consists of mount and group sections.
       These  sections can be in arbitrary order.  Any line starting with '#' is considered as
       comment line and is ignored.

適当な訳:
名前
       cgconfig.conf - libcgroupの設定ファイル

説明
       cgconfig.confはlibcgroupがコントロールグループのパラメータやマウント先を定義するのに使用する設定ファイルです
       この設定ファイルはmountとgroupのセクションで構成されています
       これらのセクションは好きな順序で書けます
       '#'で始まる行はコメント行となり、無視されます

ふむふむ…cgconfig.confにはいくつかのセクションを書いて設定をするみたいですね
続きを読みます

原文:
       mount section has the form:

              mount {
                     <controller> = <path>;
                     ...
              }


       controller
              Name of kernel subsystem. List of subsystems supported by kernel can be found in
              /proc/cgroups  file.  Libcgroup merges all subsystems mounted to the same direc‐
              tory (see Example 1) and the directory is mounted only once.


       path   The directory path, where group hierarchy associated to given controller,  shall
              be  mounted.  The directory is created automatically on cgconfig service startup
              if it does not exist and is deleted on service shutdown.

適当な訳:
       mountセッションの形式:
              mount {
                    <コントローラ> = <パス>;
                    ...
              }


       コントローラ
              カーネルのサブシステム名を指定します
              カーネルでサポートされているサブシステムのリストは/proc/cgroupsで見つけることができます
              Libcgroupは同じディレクトリにマウントされている全てのサブシステムをマージ(Example 1を参照)して
              ディレクトリは一度だけマウントされます


       パス   ディレクトリのパスを指定します
              指定されたコントローラに関連したgroup階層がここにマウントされる
              cgconfigサービスの起動時にもしディレクトリが存在しなければディレクトリが自動的に作成され
              cgconfigサービスの終了時に削除されます

これだけだと何だかわからないのでExample 1を見てみます

原文:
   Example 1
       The configuration file:

              mount {
                     cpu = /mnt/cgroups/cpu;
                     cpuacct = /mnt/cgroups/cpu;
              }

       creates the hierarchy controlled by two subsystems, with no groups  inside.  It  corre‐
       sponds to following operations:

              mkdir /mnt/cgroups/cpu
              mount -t cgroup -o cpu,cpuacct cpu /mnt/cgroups/cpu

適当な訳:
   例1
       設定ファイル:

              mount {
                     cpu = /mnt/cgroups/cpu;
                     cpuacct = /mnt/cgroups/cpu;
              }

       内部にgroupを持たないで、2つのサブシステムによってコントロールされる階層を作成します
       これは次の操作に対応してます:

              mkdir /mnt/cgroups/cpu
              mount -t cgroup -o cpu,cpuacct cpu /mnt/cgroups/cpu

よくわからないですがどうやらcgconfig.confはコマンドを簡単に実行するために設定するもののようです
この場合はマウントするディレクトリを作って
cgroupファイルシステムとして
オプションにcpu,cpuacctを指定して
マウント元をcpuにマウント先を/mnt/cgroups/cpuに指定しているみたいです
他のExampleも翻訳したいのですがその前に戻してgroupの箇所を翻訳します

原文:
group section has the form:

group <name> {
[permissions]
<controller> {
<param name> = <param value>;
...
}
...
}

name Name of the control group. It can contain only characters, which are allowed for
directory names. The groups form a tree, i.e. a control group can contain zero
or more subgroups. Subgroups can be specified using '/' delimiter.

The root control group is always created automatically in all hierarchies and it
is the base of the group hierarchy. It can be explicitly specified in cgcon‐
fig.conf file by using '.' as group name. This can be used e.g. to set its per‐
missions, as shown in Example 5.

When the parent control group of a subgroup is not specified, then it is created
automatically.

permissions
Permissions of the given control group on mounted filesystem. root has always
permission to do anything with the control group. Permissions have the follow‐
ing syntax:
perm {
task {
uid = <task user>;
gid = <task group>;
}
admin {
uid = <admin name>;
gid = <admin group>;
}
}

task user/group Name of the user and the group, which owns tasks file of the
control group. I.e. this user and members of this group has
write access to the file.

admin user/group Name of the user and the group, which owns the rest of control
group's files. These users are allowed to set subsystem parame‐
ters and create subgroups.

Permissions are related only to enclosing control group and are not inherited by
subgroups. If there is no perm section in control group definition, root:root is
owner of all files.

controller
Name of the kernel subsystem. The section can be empty, default kernel parame‐
ters will be used in this case. By specifying controller the control group and
all its parents are controlled by the specific subsystem. One control group can
be controlled by multiple subsystems, even if the subsystems are mounted to dif‐
ferent directories. Each control group must be controlled by at least one sub‐
system, so libcgroup knows, in which hierarchies the control group should be
created.

The parameters of given controller can be modified in following section enclosed
in brackets.

param name
Name of the file to set. Each controller can have zero or more parame‐
ters.

param value
Value, which should be written to the file when the control group is cre‐
ated. Optionally it can be enclosed in double quotes `"', it can contain
spaces then.

長いですね…

適当な訳:
       groupセッションの形式:

              group <名前> {
                     [パーミッション]
                     <コントローラ> {
                            <パラメータの名前> = <パラメータの値>;
                            ...
                     }
                     ...
              }


       名前   コントロールグループの名前を指定します
              これにはディレクトリ名に使うことのできる文字だけを使えます
              グループは階層構造です
              つまりはコントロールグループは0個以上のサブグループを含めることができます
              サブグループは'/'を区切り文字として使用できます

              ルートコントロールグループは常に全ての階層に自動的に作成されて
              それがgroup階層のベースです
              group階層のベースはcgconfig.confで"."をgroupの名前を使って明示的に指定できます
              例えばこれを使うとExample 5にあるようにgroup階層のベースのパーミッションを設定することができます

              サブグループの親コントロールグループが指定されていない場合は自動的に作成されます


       パーミッション
              マウントしたファイルシステムに割り当てられたコントロールグループのパーミッションを指定します
              rootは常にコントロールグループに何かをする権限を持っています
              パーミッションの構文は次の通りです:
                        perm {
                               task {
                                      uid = <task user>;
                                      gid = <task group>;
                               }
                               admin {
                                      uid = <admin user>;
                                      gid = <admin group>;
                               }
                        }


              task user/group  コントロールグループのタスクファイルを所有するユーザーとグループ
                               つまりこのユーザーやこのグループのメンバーがファイルへの書き込み、アクセスができます

              admin user/group コントロールグループの残りのファイルを所有するユーザーとグループの名前
                               これらのユーザーはサブシステムのパラメータの設定とサブグループの作成を許可される

              パーミッションはコントロールグループのみ関連しておりサブグループには継承されません
              このコントロールグループの定義に恒久的なセクションが存在しない場合は
              全てのファイルの所有者がroot:rootになる

       コントローラ
              カーネルのサブシステム名を指定します
              このセッションは空にすることができます
              その場合はデフォルトのカーネルパラメータを使うことになります
              指定したコントローラによってコントロールグループと
              それの全ての親は指定したサブシステムによってコントロールされる
              例えサブシステムが色々なディレクトリにマウントされている場合だとしても
              1つのコントロールグループは複数のサブシステムによってコントロールすることができます
              それぞれのコントロールグループは最低1つのサブシステムののコントロールを必要としている
              そういうわけでlibcgroupはコントロールグループが作成されるべき階層を知っている

              コントローラに与えるパラメータは括弧で囲まれた次のセッションで変更することができます

              パラメータの名前
                     設定するファイル名を指定します
                     それぞれのコントローラは0個以上のパラメータを持つことができます

              パラメータの値
                     コントロールグループが作成された時にファイルに書き込まれるべき値を指定します
                     必要に応じてそれをダブルクォート '"' で囲むことができます
                     すると値にスペースを含むことができます

何とかだいたいは訳せた気がします
要はgroupセッションではパーミッションとカーネルパラメータを指定できるみたいです
さて、この訳の中にExample 5という文字列があったのでそれも訳してみます

原文:
   Example 5
       The configuration file:

              mount {
                     cpu = /mnt/cgroups/cpu;
                     cpuacct = /mnt/cgroups/cpu;
              }

              group . {
                     perm {
                            task {
                                   uid = root;
                                   gid = operator;
                            }
                            admin {
                                   uid = root;
                                   gid = operator;
                            }
                     }
                     cpu {
                     }
              }

              group daemons {
                     perm {
                            task {
                                   uid = root;
                                   gid = daemonmaster;
                            }
                            admin {
                                   uid = root;
                                   gid = operator;
                            }
                     }
                     cpu {
                     }
              }
       creates  the  hierarchy  controlled  by two subsystems with one group with some special
       permissions.  It corresponds to following operations:

              mkdir /mnt/cgroups/cpu
              mount -t cgroup -o cpu,cpuacct cpu /mnt/cgroups/cpu

              chown root:operator /mnt/cgroups/cpu/*
              chown root:operator /mnt/cgroups/cpu/tasks

              mkdir /mnt/cgroups/cpu/daemons
              chown root:operator /mnt/cgroups/cpu/daemons/*
              chown root:daemonmaster /mnt/cgroups/cpu/daemons/tasks

       Users, which are members of the operator group are allowed to  administer  the  control
       groups,  i.e.  create  new  control  groups and can move processes between these groups
       without having root privileges.

       Members of daemonmaster group can move processes to daemons control group, but they can
       not move the process out of the group. Only operator or root can do that.

さっきよりは長さがマシです

適当な訳:
   例5
       設定ファイル:

              mount {
                     cpu = /mnt/cgroups/cpu;
                     cpuacct = /mnt/cgroups/cpu;
              }

              group . {
                     perm {
                            task {
                                   uid = root;
                                   gid = operator;
                            }
                            admin {
                                   uid = root;
                                   gid = operator;
                            }
                     }
                     cpu {
                     }
              }

              group daemons {
                     perm {
                            task {
                                   uid = root;
                                   gid = daemonmaster;
                            }
                            admin {
                                   uid = root;
                                   gid = operator;
                            }
                     }
                     cpu {
                     }
              }
       いくつかの特別なパーミッションがある1つのgroupがある2つのサブシステムによって
       コントロールされた階層が作られます
       これは次の操作に相当します

              mkdir /mnt/cgroups/cpu
              mount -t cgroup -o cpu,cpuacct cpu /mnt/cgroups/cpu

              chown root:operator /mnt/cgroups/cpu/*
              chown root:operator /mnt/cgroups/cpu/tasks

              mkdir /mnt/cgroups/cpu/daemons
              chown root:operator /mnt/cgroups/cpu/daemons/*
              chown root:daemonmaster /mnt/cgroups/cpu/daemons/tasks

       operatorグループのメンバーであるユーザーはコントロールグループの管理を許可されている
       つまりは新しいコントロールグループを作成したりプロセスを移動させることが
       root権限を持たなくてもこれらのグループの間でできる

       daemonmasterグループのメンバーはdaemonsコントロールグループにプロセスを移動できる
       しかしそれらはグループの外にはプロセスを移動できない
       operatorかrootのみが移動させることができます

まずはマウントするディレクトリを作って
マウントしたのちパーミッションを変更して
その中にディレクトリを作ってさらにそのパーミッションを変更しているみたいですね

ふむ…これで大体書き方がわかってきましたが
ついでなので訳してないExample 2と3と4も訳します

原文:
   Example 2
       The configuration file:

              mount {
                     cpu = /mnt/cgroups/cpu;
                     cpuacct = /mnt/cgroups/cpu;
              }

              group daemons/www {
                     perm {
                            task {
                                   uid = root;
                                   gid = webmaster;
                            }
                            admin {
                                   uid = root;
                                   gid = root;
                            }
                     }
                     cpu {
                            cpu.shares = "1000";
                     }
              }

              group daemons/ftp {
                     perm {
                            task {
                                   uid = root;
                                   gid = ftpmaster;
                            }
                            admin {
                                   uid = root;
                                   gid = root;
                            }
                     }
                     cpu {
                            cpu.shares = "500";
                     }
              }
       creates  the  hierarchy  controlled  by two subsystems with one group and two subgroups
       inside, setting one parameter.  It corresponds to following operations:

              mkdir /mnt/cgroups/cpu
              mount -t cgroup -o cpu,cpuacct cpu /mnt/cgroups/cpu

              mkdir /mnt/cgroups/cpu/daemons

              mkdir /mnt/cgroups/cpu/daemons/www
              chown root:root /mnt/cgroups/cpu/daemons/www/*
              chown root:webmaster /mnt/cgroups/cpu/daemons/www/tasks
              echo 1000 > /mnt/cgroups/cpu/daemons/www/cpu.shares

              mkdir /mnt/cgroups/cpu/daemons/ftp
              chown root:root /mnt/cgroups/cpu/daemons/ftp/*
              chown root:ftpmaster /mnt/cgroups/cpu/daemons/ftp/tasks
              echo 500 > /mnt/cgroups/cpu/daemons/ftp/cpu.shares

       The daemons group is created automatically when its first subgroup is created. All  its
       parameters have the default value and only root can access group's files.

       Since both cpuacct and cpu subsystems are mounted to the same directory, all groups are
       implicitly controlled also by cpuacct subsystem, even if there is no cpuacct section in
       any of the groups.

適当な訳:
   例2
       設定ファイル:

              mount {
                     cpu = /mnt/cgroups/cpu;
                     cpuacct = /mnt/cgroups/cpu;
              }

              group daemons/www {
                     perm {
                            task {
                                   uid = root;
                                   gid = webmaster;
                            }
                            admin {
                                   uid = root;
                                   gid = root;
                            }
                     }
                     cpu {
                            cpu.shares = "1000";
                     }
              }

              group daemons/ftp {
                     perm {
                            task {
                                   uid = root;
                                   gid = ftpmaster;
                            }
                            admin {
                                   uid = root;
                                   gid = root;
                            }
                     }
                     cpu {
                            cpu.shares = "500";
                     }
              }
       内部に1つのグループと2つのサブグループがある2つのサブシステムによって
       コントロールされた階層を作ります
       これは次の操作に相当します:

              mkdir /mnt/cgroups/cpu
              mount -t cgroup -o cpu,cpuacct cpu /mnt/cgroups/cpu

              mkdir /mnt/cgroups/cpu/daemons

              mkdir /mnt/cgroups/cpu/daemons/www
              chown root:root /mnt/cgroups/cpu/daemons/www/*
              chown root:webmaster /mnt/cgroups/cpu/daemons/www/tasks
              echo 1000 > /mnt/cgroups/cpu/daemons/www/cpu.shares

              mkdir /mnt/cgroups/cpu/daemons/ftp
              chown root:root /mnt/cgroups/cpu/daemons/ftp/*
              chown root:ftpmaster /mnt/cgroups/cpu/daemons/ftp/tasks
              echo 500 > /mnt/cgroups/cpu/daemons/ftp/cpu.shares

       daemonsグループは最初のサブグループが作成された時に自動的に作成されます
       全てのパラメータはデフォルトの値を持っておりrootだけがgroupファイルにアクセスできます

       cpuacctとcpuの両方のサブシステムは同じディレクトリにマウントしています
       全てのグループは暗黙的に例えどのgroupにもcpuacctセッションが存在しない場合でもcpuacctサブシステムが操作します

少し全貌が見えてきましたね

原文:
   Example 3
       The configuration file:


              mount {
                     cpu = /mnt/cgroups/cpu;
                     cpuacct = /mnt/cgroups/cpuacct;
              }

              group daemons {
                     cpuacct{
                     }
                     cpu {
                     }
              }
       creates  two  hierarchies and one common group in both of them.  It corresponds to fol‐
       lowing operations:

              mkdir /mnt/cgroups/cpu
              mkdir /mnt/cgroups/cpuacct
              mount -t cgroup -o cpu cpu /mnt/cgroups/cpu
              mount -t cgroup -o cpuacct cpuacct /mnt/cgroups/cpuacct

              mkdir /mnt/cgroups/cpu/daemons
              mkdir /mnt/cgroups/cpuacct/daemons

       In fact there are two groups created. One in cpuacct hierarchy, the second in cpu hier‐
       archy.  These two groups have nothing in common and can contain different subgroups and
       different tasks.

原文:
   例3
       設定ファイル:


              mount {
                     cpu = /mnt/cgroups/cpu;
                     cpuacct = /mnt/cgroups/cpuacct;
              }

              group daemons {
                     cpuacct{
                     }
                     cpu {
                     }
              }
       2つの階層とそれらの1つの共通したグループを作成します
       これは次の操作に相当します:

              mkdir /mnt/cgroups/cpu
              mkdir /mnt/cgroups/cpuacct
              mount -t cgroup -o cpu cpu /mnt/cgroups/cpu
              mount -t cgroup -o cpuacct cpuacct /mnt/cgroups/cpuacct

              mkdir /mnt/cgroups/cpu/daemons
              mkdir /mnt/cgroups/cpuacct/daemons

       実際に作成した2つのグループがあります
       1つ目はcpuacct階層 2つ目はcpu階層
       これらの2つのグループは様々なサブグループと様々なtaskを何も共有していない

訳がおかしい気がするけど雰囲気は伝わってくる
groupの中にcpuacctとcpuを書いてあるから2つグループがあることになっているのかな

原文:
   Example 4
       The configuration file:


              mount {
                     cpu = /mnt/cgroups/cpu;
                     cpuacct = /mnt/cgroups/cpuacct;
              }

              group daemons {
                     cpuacct{
                     }
              }

              group daemons/www {
                     cpu {
                            cpu.shares = "1000";
                     }
              }

              group daemons/ftp {
                     cpu {
                            cpu.shares = "500";
                     }
              }
       creates two hierarchies with few groups inside. One of groups is created in both  hier‐
       archies.

       It corresponds to following operations:

              mkdir /mnt/cgroups/cpu
              mkdir /mnt/cgroups/cpuacct
              mount -t cgroup -o cpu cpu /mnt/cgroups/cpu
              mount -t cgroup -o cpuacct cpuacct /mnt/cgroups/cpuacct

              mkdir /mnt/cgroups/cpuacct/daemons
              mkdir /mnt/cgroups/cpu/daemons
              mkdir /mnt/cgroups/cpu/daemons/www
              echo 1000 > /mnt/cgroups/cpu/daemons/www/cpu.shares
              mkdir /mnt/cgroups/cpu/daemons/ftp
              echo 500 > /mnt/cgroups/cpu/daemons/ftp/cpu.shares
       Group daemons is created in both hierarchies. In cpuacct hierarchy the group is explic‐
       itly mentioned in the configuration file. In cpu hierarchy is the group created implic‐
       itly  when  www  is created there. These two groups have nothing in common, for example
       they do not share processes and subgroups. Groups www and ftp are created only  in  cpu
       hierarchy and are not controlled by cpuacct subsystem.

原文:
   例4
       設定ファイル:


              mount {
                     cpu = /mnt/cgroups/cpu;
                     cpuacct = /mnt/cgroups/cpuacct;
              }

              group daemons {
                     cpuacct{
                     }
              }

              group daemons/www {
                     cpu {
                            cpu.shares = "1000";
                     }
              }

              group daemons/ftp {
                     cpu {
                            cpu.shares = "500";
                     }
              }
       内部にいくつかのグループがある2つの階層を作成します
       1つのグループを両方の階層に作成されます

       これは次の操作に相当します:

              mkdir /mnt/cgroups/cpu
              mkdir /mnt/cgroups/cpuacct
              mount -t cgroup -o cpu cpu /mnt/cgroups/cpu
              mount -t cgroup -o cpuacct cpuacct /mnt/cgroups/cpuacct

              mkdir /mnt/cgroups/cpuacct/daemons
              mkdir /mnt/cgroups/cpu/daemons
              mkdir /mnt/cgroups/cpu/daemons/www
              echo 1000 > /mnt/cgroups/cpu/daemons/www/cpu.shares
              mkdir /mnt/cgroups/cpu/daemons/ftp
              echo 500 > /mnt/cgroups/cpu/daemons/ftp/cpu.shares
       daemonsグループは両方の階層に作成されます
       cpuacct階層内のグループは明示的に設定ファイルに記載されています
       cpu階層内のグループはwwwを作成した時にを暗黙的に作成されます
       これら2つのグループは共有していない
       例えばこれらはプロセスとサブグループは共有していない
       wwwグループとftpグループはcpu階層にのみ作成されて
       cpuacctサブシステムからは操作ができません

要はそれぞれのサブシステムをmountした階層以下にgroupの階層が作られるみたいですね
そしてそのgroupの階層にパラメータの役割を持つファイルを書き込んでいるみたいです

しかしこれだけだとどう設定すればいいのかわからないので
とりあえず他の設定ファイルのmanを見てみましょう
これまた英語ですがman cgrules.confを読みます
こっちの方が短いです

原文:
NAME
       cgrules.conf - libcgroup configuration file

DESCRIPTION
       cgrules.conf  configuration  file is used by libcgroups to define the control groups to
       which the process belongs to.

適当な訳:
名前
       cgrules.conf - libcgroupの設定ファイル

説明
       cgrules.confの設定ファイルはどのプロセスに属するコントロールグループかを
       定義するのにlibcgroupによって使用されます

これだけだとわかりにくいので続きを訳します

原文:
       The file the contains list of rules which assign to  a  defined  group/user  a  control
       group in a subsystem (or control groups in subsystems)

       Rules have two formats:

           <user>                   <controllers>       <destination>
           <user>:<process name>    <controllers>       <destination>

       Where:

       user can be:
           - an user name
           - a group name, with @group syntax
           - the wildcard '*', for any user or group
           - '%', which is equivalent to "ditto" (useful for
             multi-line rules where different cgroups need to be
             specified for various hierarchies for a single user)

       process name is optional and it can be:
           - a process name
           - a full command path of a process

       controllers can be:
           - comma separated controller names (no spaces) or
           - * (for all mounted controllers)

       destination can be:
           - path relative to the controller hierarchy (ex. pgrp1/gid1/uid1)


       First rule which matches the criteria  will be executed.


       Any text starting with '#' is considered as a start of comment line and is ignored.

適当な訳:
       ファイルにはサブシステムで定義されたgroup又はuserのコントロールグループを
       割り当てるルールのリストが含まれています
       定義される group/user コントロールグループ サブシステム

       ルールは2つの形式があります:

           <user>                   <controllers>       <destination>
           <user>:<process name>    <controllers>       <destination>

       どこ:

       userは次のようにすることができます:
           - ユーザー名
           - グループ名の場合は@グループ名
           - 全てのユーザー又はグループにするためにはワイルドカード '*'
           - %は同上 (様々なcgroupはシングルユーザーのために様々な階層で指定する必要があり
             複数行のルールのために役に立ちます)

       process nameはオプションで次のようにすることができます
           - プロセス名
           - プロセスのフルパス

       controllersは次のようにすることができます:
           - カンマで区切られたコントローラ名 (スペースは入れずに) または
           - * (マウントされた全てのコントローラ)

       destinationは次のようにすることができます:
           - コントローラ階層からの相対パス (例えば pgrp1/gid1/uid1)


       最初に条件が一致するルールを実行しようとします


       '#'で始まる任意のテキストはコメント行の開始とみなされ無視されます

続けて例も訳します

原文:
EXAMPLES
       student         devices         /usergroup/students
       the  processes  of  user  student in the subsystem 'device' belong to the control group
       /usergroup/students.

       student:cp       devices         /usergroup/students/cp
       the 'cp' command processes of user student in the subsystem 'device' belong to the con‐
       trol group /usergroup/students/cp.

       @admin           *              admingroup/
       the  processes  which  belong  to  group admin in all subsystems belongs to the control
       group /admingroup.

       peter           cpu             test1/
       %               memory          test2/
       First line says Peter's task for cpu controller belongs to test1 control  group  second
       line says put Peter's tasks for memory controller belongs to test2/ control group

       *               *               default/
       all processes belong in all subsystems to the control group default/.  Because there is
       applied the first task which is find - it has a sense to have this row at  the  end  of
       list  to  put  the  tasks which was not mentioned in the previous rules to the default/
       control group.

適当な訳:
例
       student         devices         /usergroup/students
       サブシステムの'device'内のユーザー、studentのプロセスは
       コントロールグループ /usergroup/studentsに属しています

       student:cp       devices         /usergroup/students/cp
       サブシステムの'device'内のユーザー、studentのコマンドプロセス 'cp'は
       コントロールグループ /usrgroup/students/cpに属しています

       @admin           *              admingroup/
       全てのサブシステム内のグループ、adminに属するプロセスは
       コントロールグループ /admingroupに属しています

       peter           cpu             test1/
       %               memory          test2/
       最初の行はcpuコントローラのpeterのtaskはコントロールグループ test1/に属しています
       二行目はmemoryコントローラのコントロールグループ test2/に属してします

       *               *               default/
       全てのサブシステム内の全てのプロセスはコントロールグループ default/に属しています
       コントロールグループ default/に前のルールで記載していないタスクを入れるには
       リストの最後でこの行を読み込む
       というのは最初に見つけたタスクが適用されるためにです

最後の訳が特に自信がないけどこんな感じに書いてあると思います
要は#でコメントで

ユーザー名 サブシステム名 コントローラ階層の相対パス

を書けばいいですね
グループで指定した場合はユーザー名のところで前に@をつけるだけみたいです
そしてこれらは上に書かれている事が優先的に設定されるみたいです
上に書いてるのと同じようにしたければ%が使えるみたいです
全部を指定するには*を使うみたいです
コマンドも指定したければ

ユーザー名:コマンド名 サブシステム名 コントローラ階層の相対パス

この様にユーザー名の後ろにコロンをつけてコマンド名を付け足せばいいみたいですね
それとカンマでサブシステム名が区切れるらしいので

student:cp       devices,cpu,memory         /usergroup/students/cp

なんてやり方ができると思います

さて、libcgroupの設定ファイルの使い方が大体わかったのはいいのですが
cgroupについてはあまり理解していません
それにcpu.sharesのようなパラメータがどれだけあるのかもしれません

最近知ったのですがlinux カーネルのドキュメントは

/usr/src/linux/Documentation

ディレクトリの中に色々と書いてあるようですね
もちろんカーネルソースをパッケージ管理ソフトなどで入手している場合の話です
gentooなら

# emerge -va "sys-kernel/gentoo-sources"

にすれば入れることができます
ちなみにcgroupsのドキュメントは

/usr/src/linux/Documentation/cgroups

にあるみたいです
この中にある

00-INDEX

が目次みたいですね
恐らくこの中にパラメータ関連が書いてそうですね
ちなみにまだ実際にやってません

かなり長くなったので分けます
(まだ書いてる途中です)
正直、原文を載せる必要がなかった気がする

追記

途中にも書きましたが訳はまとめて

man cgconfig.conf
https://gist.github.com/3076435

man cgrules.conf
https://gist.github.com/3076472

ここに置いときます
いくつも今の実力じゃ訳せないようなところがあったので英語を読める人は原文を読んだほうがいいと思います