Dhaval Giani [Mon, 22 Dec 2008 18:58:11 +0000 (18:58 +0000)]
libcgroup: create function for cgroup_delete_cgroup
From: Sudhir Kumar <skumar@linux.vnet.ibm.com>
This patch creates the function test_cgroup_delete_cgroup(), to delete a
group in fs, and this way eliminates lot of redundant code. This patch
however may mesh up the numbering of testcases, which will be cleaned up
in a later patch once the functions are created for all other apis too.
Dhaval Giani [Mon, 22 Dec 2008 18:56:50 +0000 (18:56 +0000)]
libcgroup: create function for cgroup_create_cgroup
From: Sudhir Kumar <skumar@linux.vnet.ibm.com>
This patch creates the function test_cgroup_create_cgroup(), to create a
group in fs from a cgroup structure, and this way eliminates lot of redundant
code. This patch however may mesh up the numbering of testcases, which will
be cleaned up in a later patch once the functions are created for all other
apis.
Dhaval Giani [Mon, 22 Dec 2008 18:53:49 +0000 (18:53 +0000)]
libcgroup: cleanup: remove redundant parameter to function
From: Sudhir Kumar <skumar@linux.vnet.ibm.com>
There is no need to pass a separate variable for getting single/multiple
mount info, as we can get this info from the varaible received from script.
So this patch does that modification and puts the variaable fs_mounted as
global as it is never modified.
Dhaval Giani [Mon, 22 Dec 2008 18:52:08 +0000 (18:52 +0000)]
libcgroup: create function for cgroup_new_cgroup
From: Sudhir Kumar <skumar@linux.vnet.ibm.com>
This patch creates the function create_new_cgroup_ds(), to create a well
populated cgroup structure, and this way eliminates lot of redundant
code. This function internaly call other functions to provide a complete
cgroup structure. This patch breaks one of the testcases because of
the global data being used. I have fixed that in the dame patch to
maintain uniformity as this is a single line fix only and is well
commented in the code.
Balbir Singh [Wed, 17 Dec 2008 15:23:42 +0000 (15:23 +0000)]
libcgroup Test: add message
This patch fixes the NUM_MSGS error which was still 10, however there
are more type of messages to be printed. It also adds the support to just
print a new line in case there is no message to be printed.
Balbir Singh [Wed, 17 Dec 2008 15:23:16 +0000 (15:23 +0000)]
libcgroup Test: change control value
This patch changes the control values to be written to control file.
The write of value 7000000 to memory.limt_in_bytes resulted in a silent
write of 7000064, because of which modify() test case was failing.
Balbir Singh [Wed, 17 Dec 2008 15:22:50 +0000 (15:22 +0000)]
libcgroup Test: address earlier comments
This patch addresses the comments on testcases sent earlier.
Some of the corrections have been made in the coming patches which create
functions to test an api under different scenarios. The simple reason behind
that is to avoid the patches that contain only noise. For ex const strn* warnings.
I got one of the comments from Balbir Singh
"I wonder if we should also verify the
cgroup_modify_cgroup() changes by reading back the values using
cgroup_get_cgroup()"
I have not used this approach for now because of two reasons(however it would
have made life easy for me :))
1. In case cgroup_get_cgroup() fails, cgroup_modify_cgroup() test also will fail.
2. If cgroup_get_cgroup() becomes deprecated or dropped, then the testcase will
become obsolete. However I am still open to the idea. Your thoughts again??
Second comment was
"Each test case needs to be an induvidual function (can be called
from threads or other processes via a library interface)"
And the coming patches do that.
The next imp comment for me was
"I'll try and find a good test case infrastructure, if one exists
that can meet our needs."
I am eager to see some tool like that.
TODO:
Removing the hard coding of control values using config file is under progress
Balbir Singh [Wed, 17 Dec 2008 15:20:36 +0000 (15:20 +0000)]
libcgroup Test: fix-modify_cgroup-bug-in-multimnt
this patch fixes the testcase for cgroup_modify_cgroup() multi mount.
The second controller was not initialised to a value, so doing that.
/me learns the bad effects of using global data structure :)
Since the cpu.shares now has a max limit, this patch fixes all cgroup_modify_cgroup()
testcases that were failing because of this issue. This is not a permanent fix, however,
i will be changing the approach to use a configuration file for control values and
the patch will be out soon, once the function creation part is over.
Balbir Singh [Wed, 17 Dec 2008 15:19:22 +0000 (15:19 +0000)]
libcgroup Test: fix-newly-broken-test
The previous patch creating the function for attach_task() breaks a test case
because of global data usage. This patch fixes that.
(There will be functions corresponding to each API to test all the APIs)
This patch creates a function test_cgroup_attach_task() to test the libcgroup
api cgroup_attach_task() under different scenario. In the earlier approach we
were not usong functions and were testing the api sequentialy under different
conditions. The new approach has a single function for 1 api which can handle
the testing under all conditions. The advantage is that the test case becomes
thread safe as all the variables are now declared on stack. The other benefit
is that the code repetition has reduced now.
This patch creates a function test_cgroup_init() to test the libcgroup api
cgroup_init() under different scenario. In the earlier approach we were not
usong functions and were testing the api sequentialy under different conditions.
The new approach has a single function for 1 api which can handle the testing
under all conditions. The advantage is that the code repetition has reduced now.
This patch removes all the strncpy() calls that were made before each api
call to print the info messages. This patch creates an array of such info
messages, initialize them, and then frees them with the help of two functions
set_info_msgs(), called at start and free_info_msgs() called at end. The
main motto has been to avoid the global variables due to thread safety reasons.
This patch adds a testcase for libcgroup api cgroup_modify_cgroup() for
commongroup (under two controllers) in multiple mount scenario.
Again the challenge is to handle the control value as diff controllers put diff
upper limit on control value and we pick the controller dynamicaly.
So thoughts ???
This patch adds a testcase for libcgroup api cgroup_modify_cgroup() for
multiple mount scenario for second controller.
Again the challenge is to handle the control value as diff controllers put diff
upper limit on control value and we pick the controller dynamicaly.
So thoughts ???
This patch adds a testcase for libcgroup api cgroup_modify_cgroup() for
multiple mount scenario for first controller.
The challenge is to handle the control value as diff controllers put diff
upper limit on control value and we pick the controller dynamicaly.
We are going to use a config file for that which will have the controller name,
control file name and the control value. But not sure if there is any better
approach.
So thoughts ???
This patch makes the use of controllers available from script more generic.
All possible controllers in Linux kernel are to be kept as enum parameters
and a corresponding mapping is done in both, the script and binary. The
testcases are no more hardcoded with respect to controllers. The function
set_controller() need to be updated with respect to the controllers and
control file.
The challenges yet to be solved are:
(1)Choosing appropriate control file
(2)Choosing appropriate control value dynamicaly.
Balbir Singh [Wed, 17 Dec 2008 15:11:48 +0000 (15:11 +0000)]
libcgroup Test: make-controller-check-generic
The following patch adds support for a dynamical check of controllers and
choosing two of them, which are enabled in the kernel. I have given preference
to the cpu and memory controller if they exist.
I will pass these mounted controllers to the c file(will send implementation in
a next patch) and thus the c file will have no hard coding with respect to any
controller. The reason of chosing script for this part is
1. easy to implement
2. otherwise there wont be any use of script :)
One of my doubts is:
Few controllers(e.g. devices) seems not to be having a control file. Please help
me in finding the control file for each controller. Any link to documentation?
This info I need in the c file.
As per my knowledge the control files are:
*****************************
controller control_file
*****************************
cpu cpu.shares
memory memory.linit_in_bytes
debug
devices
ns
cpuacct
cpuset
Also what type of values can be written to those control files?
I need to take care before i write something stupid to a control file.
Please review the patch and give your valuable comments.
Balbir Singh [Wed, 17 Dec 2008 15:09:32 +0000 (15:09 +0000)]
libcgroup Test: add warnings
Hi,
This patch adds some warnings in case some testcses fail.
When we modify a group with nullcgroup then there is no need to
check if values are changed.
Balbir Singh [Wed, 17 Dec 2008 15:07:35 +0000 (15:07 +0000)]
libcgroup Test: fixed certain rejects
The following patch makes certain cleanups for the patchset to apply without
any rejects. However the lines of code are being changed in one of the next
patches.
Hi
The following patch adds the sanity check in c file for multiple mount case.
The parameter passed to the function decides whether the check is for single
mount or multiple mount.
Balbir Singh [Wed, 17 Dec 2008 15:01:48 +0000 (15:01 +0000)]
libcgroup Test: libcgrouptest-multimnt05
Hi
The following patch adds three testcases for libcg apis create and delete _cgroup()
and wrapper apis for multiple mount case.
The patch creates a valid cgroup structure with two controllers and after
calling to apis performs a check under both controllers.
Balbir Singh [Wed, 17 Dec 2008 15:00:37 +0000 (15:00 +0000)]
libcgroup Test: libcgrouptest-multimnt04
This patch adds a testcase for libcgroup API cgroup_delete_cgroup() testing.
The API is called under the multimount condition(FS_MOUNTED=2) and return
values are checked. The group is checked if it is deleted from the root directory
of the corresponding controller's mountpoint.
Balbir Singh [Wed, 17 Dec 2008 14:59:35 +0000 (14:59 +0000)]
libcgroup Test: libcgrouptest-multimnt03
This patch adds a testcase for libcgroup API cgroup_attach_task() testing.
The API is called under the multimount condition(FS_MOUNTED=2) and return
values are checked. The argument of the api is a valid group under one
controller's(say cpu) mountpoint. This group exist only under one
controller(cpu). So the attached task is checked under this group for this(cpu)
controller and under the root group for the other(memory) controller.
In the second call the argument is a group under other controller(memory)
and hence now task is checked under the two groups of both controllers.
In the third calll we give the argument as a non existing group, so the
return value should be ECGROUPNOTEXIST.
Balbir Singh [Wed, 17 Dec 2008 14:58:42 +0000 (14:58 +0000)]
libcgroup Test: libcgrouptest-multimnt02
This patch adds a testcase for libcgroup API cgroup_create_cgroup() testing.
The API is called under the multimount condition(FS_MOUNTED=2) and return
values are checked. The group is checked if it exists under the root directory
of the corresponding controller's mountpoint.
Balbir Singh [Wed, 17 Dec 2008 14:57:54 +0000 (14:57 +0000)]
libcgroup Test: libcgrouptest-multimnt01
This patch adds a testcase for libcgroup API cgroup_attach_task() testing.
The API is called under the multimount condition(FS_MOUNTED=2) and return
values are checked. The task pid is checked if it exists under the root
group's tasks file of both the mountpoints.
The patch also puts the common code in a function.
Balbir Singh [Wed, 17 Dec 2008 14:56:40 +0000 (14:56 +0000)]
libcgroup Test: multi-mount-script-enhanced
This patch modifies the script to handle multiple mounts. The earlier
functions are modified and new ones are added. There is still some hard
coding with respect to the number of mountpoints and controllers. I will
update this code part once I get an idea of a better design.
Dhaval Giani [Tue, 16 Dec 2008 17:29:38 +0000 (17:29 +0000)]
libcgroup: Add default group to cgconfig
From: Balbir Singh <balbir@linux.vnet.ibm.com>
As discussed in the previous thread
http://article.gmane.org/gmane.comp.lib.libcg.devel/139, we don't have
the concept of default groups and tasks should be able to return back
to their default group when done.
Here is a fix to the cgconfig script to fix the issue. Please review,
comment on it.
Dhaval Giani [Tue, 16 Dec 2008 17:20:11 +0000 (17:20 +0000)]
libcgroup: Fix broken cgred
From: Balbir Singh <balbir@linux.vnet.ibm.com>
cgred is broken, in that there are some checks that fail and we use
--config to start the daemon and that is not supported. We also use
-12 as the signal to killproc.
Dhaval Giani [Tue, 16 Dec 2008 17:14:33 +0000 (17:14 +0000)]
libcgroup: Add default group to cgconfig
From: Balbir Singh <balbir@linux.vnet.ibm.com>
As discussed in the previous thread
http://article.gmane.org/gmane.comp.lib.libcg.devel/139, we don't have
the concept of default groups and tasks should be able to return back
to their default group when done.
Here is a fix to the cgconfig script to fix the issue. Please review,
comment on it.
Balbir Singh [Mon, 1 Dec 2008 09:50:00 +0000 (09:50 +0000)]
From: SanjayKumar J <vjsanjay@gmail.com>
Consistent Error checking for group_admin_perm
Signed-off-by: SanjayKumar J <vjsanjay@gmail.com> Signed-off-by: Balbir Singh <balbir@linux.vnet.ibm.com>
[Balbir - change prefix in Makefile to /usr, so that make install does sensible
things]
Dhaval Giani [Mon, 10 Nov 2008 13:10:07 +0000 (13:10 +0000)]
libcgroup: Make cgconfigparser more verbose
As per http://sourceforge.net/tracker/?func=detail&atid=1043649&aid=2128139&group_id=218421
cgconfigparser was not exiting silently for wrong usage. Let's
let the user know they are using wrong syntax.
The automatic classification engine (cgexec, cgclassify, pam_cgroup)
classify tasks. It is useful for an application to know where it has
been classified. I propose to add a new API
cgroup_get_current_controller_path() that returns the current
classification directory for the specified controller. One can easily
add on and build new API that will return paths of all mounted
controllers, but I want to start with something simple and useful.
I've also added a bunch of test cases for the same purpose.
Test output
# ./pathtest.sh
Test FAIL, get path failed for controller cpuset
Test PASS, controller cpu path /default
Test PASS, controller cpuacct path /default
Test PASS, controller memory path /default
Test FAIL, get path failed for controller memrlimit
I mounted just cpu, cpuacct and memory, thus the path for cpuset and
memrlimit could not be found (as expected).
Balbir Singh [Fri, 22 Aug 2008 16:44:17 +0000 (16:44 +0000)]
This patch adds cgroup_create_cgroup_from_parent() API. I've tested it
with a modified version of libcg_ba (basic acceptance tests), that I'll send
out later. I've also fixed a couple of bugs, I'll list them in order and
if desired, I'll split out the patches so that the enhancements can be
separate from the bug fixes
1. Fix cg_create_control_group() to succeed if the directory already exists
2. We can't always append a control_file, we need to open it "r+"
3. It's OK for writing values to a control_file to fail, since some of
them are read-only and some may not exist in hierarchies below the root
4. Skip over directories while trying to read control file's name value pairs
5. In cg_rd_ctlr_file we don't allocate any memory to value, directly fscanf
into it, that's been fixed
6. There might be more fixes that might already be present in trunk, since
I hope I've not redone a lot of the fixes, I had branched of trunk very
recently
Changelog v2
------------
1. Refactor cgroup_free_controllers() and use it in
cgroup_create_cgroup_from_parent()
2. Check for strdup failure
3. Check if dst == src
TODO:
1. Use cg_add_controller() API
2. Use cg_add_value_string() API
I'll send out patches for the TODOs later.
I've also updated the basic acceptance test (libcg_ba.cpp)
Dhaval Giani [Thu, 14 Aug 2008 15:05:48 +0000 (15:05 +0000)]
Fix configuration assert when multiple controllers are enabled
Since we support multiple controllers, asserting is no longer a good
idea.
TODO: Support other controllers, memory, cpu and cpuacct (possibly
cpusets as well). Well, this code is obsolete and will be replaced
by the newer cgroup API.
Dhaval Giani [Thu, 14 Aug 2008 11:10:23 +0000 (11:10 +0000)]
libcgroup: Fix the delete API
The delete call was returning a wrong value even on success.
The reason was because in the fallback path, we try to delete
all the groups again. Now it is possible that a group might
have already been deleted and we return a wrong value.
Change the API to check if the group exists before trying to rmdir
it in the error path.
Dhaval Giani [Wed, 13 Aug 2008 20:04:51 +0000 (20:04 +0000)]
cgclassify: A command line tool to classify/re-classify already running task
From: Vivek Goyal <vgoyal@redhat.com>
o cgclassify, a command line tool to put a list of pids to the right cgroup
based on rules in /etc/cgrules.conf. It can be mainly used for
reclassification of tasks which are already running. Can think of two
use cases.
- During initial bootup, after cgroups are mounted, one needs to
move tasks (started beofore cgroups were mounted) into right
cgroup.
- Once can choose to reclassify the tasks if admin has changed the
rules and thinks a group of tasks should reclassified based on
new rules.
Dhaval Giani [Wed, 13 Aug 2008 20:01:16 +0000 (20:01 +0000)]
cgexec: A command line tool to execute a task in a cgroup
From: Vivek Goyal <vgoyal@redhat.com>
o cgexec, a command line tool for placing the task in right cgroup
in advance so that no help is needed from rules daemon and user can
avoid delay in execution of rules.
Dhaval Giani [Wed, 13 Aug 2008 19:58:05 +0000 (19:58 +0000)]
libcgroup: New API interfaces for task placement
From: Vivek Goyal <vgoyal@redhat.com>
Enhancement to libcg to do following.
- Parse the /etc/cgrules.conf file and place the task in the right cgroup.
- Exported two APIs which can place the task based on /etc/cgrules.conf
or based on cgroup explicitly specified by the caller.
- There can be multiple users.
- PAM module (pam_cgroup)
- cgexec tool
- cgclassify tool
- APIs can be directly used by other cgroup aware user progarams.
- Classification daemon
projects / thirdparty / libcgroup.git / log
