Report CPU usage in CFS Cgroup directories
Adds a cpu.usage file to the CFS cgroup that reports CPU usage in
milliseconds for that cgroup's tasks
This replaces the example CPU Accounting CGroup subsystem that
was merged into mainline last week.
Signed-off-by: Paul Menage [EMAIL PROTECTED
On 10/17/07, Cedric Le Goater <[EMAIL PROTECTED]> wrote:
> Hello !
>
> While polling the contents of a cgroup task file, I caught the
> following corruption. Is there a known race (and a fix) or should
> I start digging ?
>
> list_add corruption. next->prev should be prev (80a3f338), but
On 10/17/07, Cedric Le Goater [EMAIL PROTECTED] wrote:
Hello !
While polling the contents of a cgroup task file, I caught the
following corruption. Is there a known race (and a fix) or should
I start digging ?
list_add corruption. next-prev should be prev (80a3f338), but was
On 10/17/07, Cedric Le Goater <[EMAIL PROTECTED]> wrote:
> Hello !
>
> While polling the contents of a cgroup task file, I caught the
> following corruption. Is there a known race (and a fix) or should
> I start digging ?
Not a known race, no. Sorry, didn't have time to look at this
yesterday
On 10/17/07, Cedric Le Goater [EMAIL PROTECTED] wrote:
Hello !
While polling the contents of a cgroup task file, I caught the
following corruption. Is there a known race (and a fix) or should
I start digging ?
Not a known race, no. Sorry, didn't have time to look at this
yesterday since I
to that hierarchy.
Signed-off-by: Paul Menage <[EMAIL PROTECTED]>
---
Several people have commented that /proc/cgroups is too confusing or
contains strange information. Here's an attempt to simplify it. New
typical output looks like:
#subsys_namehierarchy num_cgroups
cpuset 1
to that hierarchy.
Signed-off-by: Paul Menage [EMAIL PROTECTED]
---
Several people have commented that /proc/cgroups is too confusing or
contains strange information. Here's an attempt to simplify it. New
typical output looks like:
#subsys_namehierarchy num_cgroups
cpuset 1 2
number of places, and renames
the CONT_* enum members to CGRP_*.
This patch is not intended to have any effect on the generated code;
the output of "objdump -d kernel/cgroup.o" is unchanged.
Signed-off-by: Paul Menage <[EMAIL PROTECTED]>
---
kernel/cgroup.c | 496
Paul Jackson wrote:
Any chance you could provide a patch that works against cgroups?
Fix cpusets update_cpumask
Cause writes to cpuset "cpus" file to update cpus_allowed for member
tasks:
- collect batches of tasks under tasklist_lock and then call
set_cpus_allowed() on them outside the
Paul Jackson wrote:
Any chance you could provide a patch that works against cgroups?
Fix cpusets update_cpumask
Cause writes to cpuset cpus file to update cpus_allowed for member
tasks:
- collect batches of tasks under tasklist_lock and then call
set_cpus_allowed() on them outside the
is not intended to have any effect on the generated code;
the output of objdump -d kernel/cgroup.o is unchanged.
Signed-off-by: Paul Menage [EMAIL PROTECTED]
---
kernel/cgroup.c | 496
1 file changed, 248 insertions(+), 248 deletions(-)
Index
On 10/15/07, Paul Jackson <[EMAIL PROTECTED]> wrote:
> > currently against an older kernel
>
> ah .. which older kernel?
2.6.18, but I can do a version against 2.6.23-mm1.
> + if (!retval) {
> + cpus_allowed = cpuset_cpus_allowed(p);
> + if
Paul Jackson wrote:
Paul M wrote:
Here's an alternative for consideration, below.
I don't see the alternative -- I just see my patch, with the added
blurbage:
#12 - /usr/local/google/home/menage/kernel9/linux/kernel/cpuset.c
# action=edit type=text
Should I be increasing my
Paul Jackson wrote:
Paul M, David R, others -- how does this look?
Looks plausible, although as David comments I don't think it handles a
concurrent CPU hotplug/unplug. Also I don't like the idea of doing a
cgroup_lock() across sched_setaffinity() - cgroup_lock() can be held for
relatively
Paul Jackson wrote:
Paul M, David R, others -- how does this look?
Looks plausible, although as David comments I don't think it handles a
concurrent CPU hotplug/unplug. Also I don't like the idea of doing a
cgroup_lock() across sched_setaffinity() - cgroup_lock() can be held for
relatively
Paul Jackson wrote:
Paul M wrote:
Here's an alternative for consideration, below.
I don't see the alternative -- I just see my patch, with the added
blurbage:
#12 - /usr/local/google/home/menage/kernel9/linux/kernel/cpuset.c
# action=edit type=text
Should I be increasing my
On 10/15/07, Paul Jackson [EMAIL PROTECTED] wrote:
currently against an older kernel
ah .. which older kernel?
2.6.18, but I can do a version against 2.6.23-mm1.
+ if (!retval) {
+ cpus_allowed = cpuset_cpus_allowed(p);
+ if (!cpus_subset(new_mask,
On 10/6/07, David Rientjes <[EMAIL PROTECTED]> wrote:
>
> It can race with sched_setaffinity(). It has to give up tasklist_lock as
> well to call set_cpus_allowed() and can race
>
> cpus_allowed = cpuset_cpus_allowed(p);
> cpus_and(new_mask, new_mask, cpus_allowed);
>
On 10/6/07, David Rientjes [EMAIL PROTECTED] wrote:
It can race with sched_setaffinity(). It has to give up tasklist_lock as
well to call set_cpus_allowed() and can race
cpus_allowed = cpuset_cpus_allowed(p);
cpus_and(new_mask, new_mask, cpus_allowed);
retval =
ing and end of passed in masks, this
> doesn't make any visible difference in behaviour. But it's
> one or two hundred kernel text bytes smaller, and easier to
> understand.
>
> Signed-off-by: Paul Jackson <[EMAIL PROTECTED]>
Reviewed-by: Paul Menage <[EMAIL PROTECTED]>
Look
On 10/6/07, David Rientjes <[EMAIL PROTECTED]> wrote:
> The getting and putting of the tasks will prevent them from exiting or
> being deallocated prematurely. But this is also a critical section that
> will need to be protected by some mutex so it doesn't race with other
> set_cpus_allowed().
On 10/6/07, Paul Jackson <[EMAIL PROTECTED]> wrote:
> David wrote:
> > It would probably be better to just save references to the tasks.
> >
> > struct cgroup_iter it;
> > struct task_struct *p, **tasks;
> > int i = 0;
> >
> > cgroup_iter_start(cs->css.cgroup, );
> >
On 10/6/07, Paul Jackson <[EMAIL PROTECTED]> wrote:
>
> This isn't working for me.
>
> The key kernel routine for updating a tasks cpus_allowed
> cannot be called while holding a spinlock.
>
> But the above loop holds a spinlock, css_set_lock, between
> the cgroup_iter_start and the
On 10/6/07, Paul Jackson [EMAIL PROTECTED] wrote:
This isn't working for me.
The key kernel routine for updating a tasks cpus_allowed
cannot be called while holding a spinlock.
But the above loop holds a spinlock, css_set_lock, between
the cgroup_iter_start and the cgroup_iter_end.
I end
On 10/6/07, Paul Jackson [EMAIL PROTECTED] wrote:
David wrote:
It would probably be better to just save references to the tasks.
struct cgroup_iter it;
struct task_struct *p, **tasks;
int i = 0;
cgroup_iter_start(cs-css.cgroup, it);
while ((p =
On 10/6/07, David Rientjes [EMAIL PROTECTED] wrote:
The getting and putting of the tasks will prevent them from exiting or
being deallocated prematurely. But this is also a critical section that
will need to be protected by some mutex so it doesn't race with other
set_cpus_allowed().
Is that
any visible difference in behaviour. But it's
one or two hundred kernel text bytes smaller, and easier to
understand.
Signed-off-by: Paul Jackson [EMAIL PROTECTED]
Reviewed-by: Paul Menage [EMAIL PROTECTED]
Looks fine to me.
Paul
-
To unsubscribe from this list: send the line unsubscribe
On 10/2/07, Hugh Dickins <[EMAIL PROTECTED]> wrote:
>
> I accept that full swap control is something you're intending to add
> incrementally later; but the current state doesn't make sense to me.
One comment on swap - ideally it should be a separate subsystem from
the memory controller. That way
On 10/4/07, Paul Jackson <[EMAIL PROTECTED]> wrote:
> Paul M,
>
> This snippet from the memory allocation hot path worries me a bit.
>
> Once per memory page allocation, we go through here, needing to peak inside
> the current tasks cpuset to see if it has changed (it's 'mems_generation'
> value
On 10/4/07, Paul Jackson [EMAIL PROTECTED] wrote:
Paul M,
This snippet from the memory allocation hot path worries me a bit.
Once per memory page allocation, we go through here, needing to peak inside
the current tasks cpuset to see if it has changed (it's 'mems_generation'
value doesn't
On 10/2/07, Hugh Dickins [EMAIL PROTECTED] wrote:
I accept that full swap control is something you're intending to add
incrementally later; but the current state doesn't make sense to me.
One comment on swap - ideally it should be a separate subsystem from
the memory controller. That way
On 10/3/07, Paul Jackson <[EMAIL PROTECTED]> wrote:
>
> I can't say for sure, but I suspect that if cgroups had always
> been cgroups (short for control groups), then these local 'cont'
> variables would have a different name.
Oh, absolutely. I just refrained from changing them in the rename
On 10/3/07, Paul Jackson <[EMAIL PROTECTED]> wrote:
>
> But now (correct me if I'm wrong here) cgroups has a per-cgroup task
> list, and the above loop has cost linear in the number of tasks
> actually in the cgroup, plus (unfortunate but necessary and tolerable)
> the cost of taking a global
On 10/3/07, Paul Jackson <[EMAIL PROTECTED]> wrote:
>
> So far as I can tell, this patch just removes a minor optimization,
It's not minor for any subsystem that has a non-trivial attach() operation.
>
> Any further suggestions, or embarrassing (;) questions?
>
What was wrong with my suggestion
On 10/3/07, Paul Menage <[EMAIL PROTECTED]> wrote:
>
> What's wrong with, in update_cpumask(), doing a loop across all
> members of the cgroup and updating their cpus_allowed fields?
i.e. something like:
struct cgroup_iter it;
struct task_struct *p;
while ((p = cgroup_iter_next
On 10/3/07, Paul Jackson <[EMAIL PROTECTED]> wrote:
>
> So after changing the 'cpus' of a cpuset, you (something in
> user space) then has to rewrite every pid in that cpusets
> tasks file back to that same tasks file, in order to get the
> change to be applied to each of those tasks, and get them
On 10/3/07, Paul Jackson <[EMAIL PROTECTED]> wrote:
>
> Yes, something in user space has to do it. It's part of the
> kernel-user cpuset API. If you change a cpuset's 'cpus', then
> you have to rewrite each pid in its 'tasks' file back to that
> 'tasks' file in order to get that 'cpus' change to
On 10/3/07, Paul Jackson <[EMAIL PROTECTED]> wrote:
> From: Paul Jackson <[EMAIL PROTECTED]>
>
> The code in kernel/cgroup.c attach_task() which skips the
> attachment of a task to the group it is already in has to be
> removed. Cpusets depends on reattaching a task to its current
> cpuset, in
On 10/3/07, Paul Jackson <[EMAIL PROTECTED]> wrote:
>
> - What are these apparent 'exec notifications' that are provided to
>user space that the following mentions - I cannot find any other
>mention of them:
>
> With the ability to classify tasks differently for different
>
On 10/3/07, Paul Jackson [EMAIL PROTECTED] wrote:
- What are these apparent 'exec notifications' that are provided to
user space that the following mentions - I cannot find any other
mention of them:
With the ability to classify tasks differently for different
On 10/3/07, Paul Jackson [EMAIL PROTECTED] wrote:
From: Paul Jackson [EMAIL PROTECTED]
The code in kernel/cgroup.c attach_task() which skips the
attachment of a task to the group it is already in has to be
removed. Cpusets depends on reattaching a task to its current
cpuset, in order to
On 10/3/07, Paul Jackson [EMAIL PROTECTED] wrote:
Yes, something in user space has to do it. It's part of the
kernel-user cpuset API. If you change a cpuset's 'cpus', then
you have to rewrite each pid in its 'tasks' file back to that
'tasks' file in order to get that 'cpus' change to be
On 10/3/07, Paul Jackson [EMAIL PROTECTED] wrote:
So after changing the 'cpus' of a cpuset, you (something in
user space) then has to rewrite every pid in that cpusets
tasks file back to that same tasks file, in order to get the
change to be applied to each of those tasks, and get them to
On 10/3/07, Paul Menage [EMAIL PROTECTED] wrote:
What's wrong with, in update_cpumask(), doing a loop across all
members of the cgroup and updating their cpus_allowed fields?
i.e. something like:
struct cgroup_iter it;
struct task_struct *p;
while ((p = cgroup_iter_next(cs-css.cgroup
On 10/3/07, Paul Jackson [EMAIL PROTECTED] wrote:
So far as I can tell, this patch just removes a minor optimization,
It's not minor for any subsystem that has a non-trivial attach() operation.
Any further suggestions, or embarrassing (;) questions?
What was wrong with my suggestion from a
On 10/3/07, Paul Jackson [EMAIL PROTECTED] wrote:
But now (correct me if I'm wrong here) cgroups has a per-cgroup task
list, and the above loop has cost linear in the number of tasks
actually in the cgroup, plus (unfortunate but necessary and tolerable)
the cost of taking a global
On 10/3/07, Paul Jackson [EMAIL PROTECTED] wrote:
I can't say for sure, but I suspect that if cgroups had always
been cgroups (short for control groups), then these local 'cont'
variables would have a different name.
Oh, absolutely. I just refrained from changing them in the rename
since the
Comment fixed, to match the actual arguments.
Signed-off-by: Balaji Rao <[EMAIL PROTECTED]>
Signed-off-by: Paul Menage <[EMAIL PROTECTED]>
---
kernel/cgroup.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Index: container-2.6.23-rc8-mm1/ker
Add write_uint() helper method for cgroup subsystems
This helper is analagous to the read_uint() helper method for
reporting u64 values to userspace. It's designed to reduce the amount
of boilerplate requierd for creating new cgroup subsystems.
Signed-off-by: Paul Menage <[EMAIL PROTEC
Add write_uint() helper method for cgroup subsystems
This helper is analagous to the read_uint() helper method for
reporting u64 values to userspace. It's designed to reduce the amount
of boilerplate requierd for creating new cgroup subsystems.
Signed-off-by: Paul Menage [EMAIL PROTECTED
Comment fixed, to match the actual arguments.
Signed-off-by: Balaji Rao [EMAIL PROTECTED]
Signed-off-by: Paul Menage [EMAIL PROTECTED]
---
kernel/cgroup.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Index: container-2.6.23-rc8-mm1/kernel/cgroup.c
On 9/9/07, Pavel Machek <[EMAIL PROTECTED]> wrote:
>
> One of the cpus was unplugged during suspend... perhaps some
> save/restore is needed during hotplug/unplug?
Or else keep track separately in cpusets of
- cpus that the cpuset can run on
- cpus that the admin has specified for the cpu to run
On 9/9/07, Pavel Machek [EMAIL PROTECTED] wrote:
One of the cpus was unplugged during suspend... perhaps some
save/restore is needed during hotplug/unplug?
Or else keep track separately in cpusets of
- cpus that the cpuset can run on
- cpus that the admin has specified for the cpu to run on
From: "Serge E. Hallyn" <[EMAIL PROTECTED]>
(container->cgroup renaming by Paul Menage <[EMAIL PROTECTED]>)
When a task enters a new namespace via a clone() or unshare(), a new cgroup
is created and the task moves into it.
This version names cgroups which are au
--
This patchset renames "Task Containers" to "Control Groups", in line with
recent discussions.
These patches are drop-in replacements for those of the same names in
the current -mm tree, as listed at the bottom of this email. I have
tried to keep the patch names (based on the description
Add support for cgroup_clone(), a way to create new cgroups intended to
be used for systems such as namespace unsharing. A new subsystem callback,
post_clone(), is added to allow subsystems to automatically configure cloned
cgroups.
Signed-off-by: Paul Menage <[EMAIL PROTEC
From: Balbir Singh <[EMAIL PROTECTED]>
(container->cgroup renaming by Paul Menage <[EMAIL PROTECTED]>)
Allow tasks to migrate from one cgroup to the other. We migrate
mm_struct's mem_cgroup only when the thread group id migrates.
Signed-off-by: Balbir Singh <[EMAIL PROT
in a reference
count being missed from the directory dentry.
This patch removes cgroup_get_dentry() and replaces it with direct calls
to lookup_one_len(); the initialization of cgroupfs dentry ops is done
now in cgroup_create_file() at dentry creation time.
Signed-off-by: Paul Menage <[EMAIL PROTEC
From: Cedric Le Goater <[EMAIL PROTECTED]>
(container->cgroup renaming by Paul Menage <[EMAIL PROTECTED]>)
some cosmetic changes to init/Kconfig to make the subsystem list
under cgroups look nicer when CONFIG_CGROUPS=y.
also changed the 'select' to 'depends on' for the name
From: Pavel Emelianov <[EMAIL PROTECTED]>
(container->cgroup renaming by Paul Menage <[EMAIL PROTECTED]>)
Out of memory handling for cgroups over their limit. A task from the
cgroup over limit is chosen using the existing OOM logic and killed.
TODO:
1. As discussed in the
From: Pavel Emelianov <[EMAIL PROTECTED]>
(container->cgroup renaming by Paul Menage <[EMAIL PROTECTED]>)
Basic setup routines, the mm_struct has a pointer to the cgroup that
it belongs to and the the page has a page_cgroup associated with it.
Signed-off-by: Pavel Emelianov &l
From: Balbir Singh <[EMAIL PROTECTED]>
(container->cgroup renaming by Paul Menage <[EMAIL PROTECTED]>)
Add the accounting hooks. The accounting is carried out for RSS and Page
Cache (unmapped) pages. There is now a common limit and accounting for both.
The RSS accounti
their release agents invoked by
the workqueue task are linked on to a list.
Signed-off-by: Paul Menage <[EMAIL PROTECTED]>
---
include/linux/cgroup.h | 11
kernel/cgroup.c| 425
2 files changed, 393 insertions(+), 43 deletions(-)
diff -puN
i
Add the per-directory "tasks" file for cgroupfs mounts; this allows the
user to determine which tasks are members of a cgroup by reading a
cgroup's "tasks", and to move a task into a cgroup by writing its pid to
its "tasks".
Signed-off-by: Paul Menage <[EMAI
From: Balbir Singh <[EMAIL PROTECTED]>
(container->cgroup renaming by Paul Menage <[EMAIL PROTECTED]>)
Make page_referenced() cgroup aware. Without this patch, page_referenced()
can cause a page to be skipped while reclaiming pages. This patch ensures
that other cgroups do
From: Balbir Singh <[EMAIL PROTECTED]>
(container->cgroup renaming by Paul Menage <[EMAIL PROTECTED]>)
Change the interface to use bytes instead of pages. Page sizes can vary
across platforms and configurations. A new strategy routine has been added
to the resource counters
From: Pavel Emelianov <[EMAIL PROTECTED]>
(container->cgroup renaming by Paul Menage <[EMAIL PROTECTED]>)
Introduce generic structures and routines for resource accounting.
Each resource accounting cgroup is supposed to aggregate it,
cgroup_subsystem_state and its resource-s
From: David Rientjes <[EMAIL PROTECTED]>
(container->cgroup renaming by Paul Menage <[EMAIL PROTECTED]>)
There's a gotcha in res_counter_charge_locked() because of C99 6.3.1.8(1)
since both counter->limit and 'val' are of unsigned long type, the result
of the subtractio
ode will ultimately be a child directory
of the parent whose i_mutex is nested outside of cgroup_mutex.
Signed-off-by: Paul Menage <[EMAIL PROTECTED]>
Acked-by: Peter Zijlstra <[EMAIL PROTECTED]>
---
kernel/cgroup.c | 17 +++--
1 files changed, 7 insertions(+), 10 deletion
From: Andrew Morton <[EMAIL PROTECTED]>
(container->cgroup renaming by Paul Menage <[EMAIL PROTECTED]>)
kernel/taskstats.c: In function 'cgroupstats_user_cmd':
kernel/taskstats.c:414: error: dereferencing pointer to incomplete type
Signed-off-by: Andrew Morton <[EMAIL PROTEC
e the same cgroup assignments, this reduces
overall space usage and keeps the size of the task_struct down (three pointers
added to task_struct compared to a non-cgroups kernel, no matter how many
subsystems are registered).
Signed-off-by: Paul Menage <[EMAIL PROTECTED]>
---
Documentation/cg
Updates cgroup_clone() to use lookup_one_len() rather than
cgroup_get_dentry(). Originally part of
task-cgroupsv11-basic-task-cgroup-framework-cgroups-fix-refcount-bug
but split out by akpm for the -mm tree.
Signed-off-by: Paul Menage <[EMAIL PROTECTED]>
---
kernel/cgroup.c |2 +-
Handle reading /proc/self/cpuset when cpusets isn't mounted.
Signed-off-by: Paul Menage <[EMAIL PROTECTED]>
---
kernel/cgroup.c |9 +
1 file changed, 9 insertions(+)
diff -puN kernel/cgroup.c~task-cgroupsv11-basic-task-cgroup-framework-fix
kernel/cgroup.c
--- a/kernel/cg
From: Balbir Singh <[EMAIL PROTECTED]>
(container->cgroup renaming by Paul Menage <[EMAIL PROTECTED]>)
Signed-off-by: Balbir Singh <[EMAIL PROTECTED]>
Signed-off-by: Paul Menage <[EMAIL PROTECTED]>
---
Documentation/controllers/memory.txt | 259
From: Balbir Singh <[EMAIL PROTECTED]>
(container->cgroup renaming by Paul Menage <[EMAIL PROTECTED]>)
Setup the memory cgroup and add basic hooks and controls to integrate
and work with the cgroup.
Signed-off-by: Balbir Singh <[EMAIL PROTECTED]>
Signed-off-by: Paul Men
From: Andrew Morton <[EMAIL PROTECTED]>
(container->cgroup renaming by Paul Menage <[EMAIL PROTECTED]>)
mm/memcontrol.c: In function 'mem_cgroup_charge':
mm/memcontrol.c:337: error: implicit declaration of function 'congestion_wait'
Signed-off-by: Andrew Morton <[EMAIL PROT
(first use in
this function)
kernel/cgroup.c:574: error: (Each undeclared identifier is reported only once)
Signed-off-by: Andrew Morton <[EMAIL PROTECTED]>
Signed-off-by: Paul Menage <[EMAIL PROTECTED]>
---
kernel/cgroup.c |1 +
1 file changed, 1 insertion(+)
diff -puN
kernel/c
From: Balbir Singh <[EMAIL PROTECTED]>
(container->cgroup renaming by Paul Menage <[EMAIL PROTECTED]>)
Add the page_cgroup to the per cgroup LRU. The reclaim algorithm has
been modified to make the isolate_lru_pages() as a pluggable component. The
scan_control data struct
ed-off-by: Paul Menage <[EMAIL PROTECTED]>
---
include/linux/cgroup_subsys.h |6
include/linux/cpu_acct.h | 14 ++
init/Kconfig |7 +
kernel/Makefile |1
kernel/cpu_acct.c| 186 +
ke
Add:
/proc/cgroups - general system info
/proc/*/cgroup - per-task cgroup membership info
Signed-off-by: Paul Menage <[EMAIL PROTECTED]>
---
fs/proc/base.c|7 +
include/linux/cgroup.h |2
kernel/cgroup.c| 132
3 files c
From: Balbir Singh <[EMAIL PROTECTED]>
(container->cgroup renaming by Paul Menage <[EMAIL PROTECTED]>)
Choose if we want cached pages to be accounted or not. By default both are
accounted for. A new set of tunables are added.
echo -n 1 > mem_control_type
switches the acc
From: Balbir Singh <[EMAIL PROTECTED]>
(container->cgroup renaming by Paul Menage <[EMAIL PROTECTED]>)
This patch is inspired by the discussion at
http://lkml.org/lkml/2007/4/11/187 and implements per cgroup statistics
as suggested by Andrew Morton in http://lkml.org/lkm
From: Balbir Singh <[EMAIL PROTECTED]>
(container->cgroup renaming by Paul Menage <[EMAIL PROTECTED]>)
Nick Piggin pointed out that swap cache and page cache addition routines
could be called from non GFP_KERNEL contexts. This patch makes the
charging routine aware of the gfp con
This example subsystem exports debugging information as an aid to diagnosing
refcount leaks, etc, in the cgroup framework.
Signed-off-by: Paul Menage <[EMAIL PROTECTED]>
---
include/linux/cgroup_subsys.h |4 +
init/Kconfig | 10 ++
kernel/Ma
Adds the necessary hooks to the fork() and exit() paths to ensure that
new children inherit their parent's cgroup assignments, and that exiting
processes release reference counts on their cgroups.
Signed-off-by: Paul Menage <[EMAIL PROTECTED]>
---
include/linux/cgroup.h |6 +
p_one_len(), this resulted in a
reference count being missed from the directory dentry.
This patch removes container_get_dentry() and replaces it with direct
calls to lookup_one_len(); the initialization of containerfs dentry
ops is done now in container_create_file() at dentry creation time.
This is already fixed in -mm - see
task-containersv11-basic-task-container-framework-containers-fix-refcount-bug.patch
task-containersv11-add-container_clone-interface-containers-fix-refcount-bug.patch
Paul
On 9/15/07, Paul Jackson <[EMAIL PROTECTED]> wrote:
> Paul Menage,
>
On 9/15/07, Andrew Morton <[EMAIL PROTECTED]> wrote:
>
> Yeah. Bug, surely. But I guess it's always been there.
>
> What are the implications of this for cpusets-via-containers?
>
I don't think it should be any different from the previous version - I
tried to avoid touching those bits of
On 9/15/07, Andrew Morton <[EMAIL PROTECTED]> wrote:
> >
> > + BUG_ON(!atomic_read(>d_count));
> > repeat:
> > if (atomic_read(>d_count) == 1)
> > might_sleep();
>
> eek, much too aggressive.
How about the equivalent BUG_ON() in dget()? I figure that they ought
to both be
On 9/15/07, Paul Jackson <[EMAIL PROTECTED]> wrote:
> From: Paul Jackson <[EMAIL PROTECTED]>
>
> Paul Menage - in pre-container cpusets, a few config files enabled
> cpusets by default. Could you blend the following patch into your
> container patch set, so that cpuset
On 9/15/07, Paul Jackson [EMAIL PROTECTED] wrote:
From: Paul Jackson [EMAIL PROTECTED]
Paul Menage - in pre-container cpusets, a few config files enabled
cpusets by default. Could you blend the following patch into your
container patch set, so that cpusets continue to be configured
On 9/15/07, Andrew Morton [EMAIL PROTECTED] wrote:
+ BUG_ON(!atomic_read(dentry-d_count));
repeat:
if (atomic_read(dentry-d_count) == 1)
might_sleep();
eek, much too aggressive.
How about the equivalent BUG_ON() in dget()? I figure that they ought
to both be
On 9/15/07, Andrew Morton [EMAIL PROTECTED] wrote:
Yeah. Bug, surely. But I guess it's always been there.
What are the implications of this for cpusets-via-containers?
I don't think it should be any different from the previous version - I
tried to avoid touching those bits of cpusets where
This is already fixed in -mm - see
task-containersv11-basic-task-container-framework-containers-fix-refcount-bug.patch
task-containersv11-add-container_clone-interface-containers-fix-refcount-bug.patch
Paul
On 9/15/07, Paul Jackson [EMAIL PROTECTED] wrote:
Paul Menage,
When I run a cpuset
dentry.
This patch removes container_get_dentry() and replaces it with direct
calls to lookup_one_len(); the initialization of containerfs dentry
ops is done now in container_create_file() at dentry creation time.
Signed-off-by: Paul Menage [EMAIL PROTECTED]
---
kernel/container.c | 26
This example subsystem exports debugging information as an aid to diagnosing
refcount leaks, etc, in the cgroup framework.
Signed-off-by: Paul Menage [EMAIL PROTECTED]
---
include/linux/cgroup_subsys.h |4 +
init/Kconfig | 10 ++
kernel/Makefile |1
Adds the necessary hooks to the fork() and exit() paths to ensure that
new children inherit their parent's cgroup assignments, and that exiting
processes release reference counts on their cgroups.
Signed-off-by: Paul Menage [EMAIL PROTECTED]
---
include/linux/cgroup.h |6 +
kernel/cgroup.c
From: Balbir Singh [EMAIL PROTECTED]
(container-cgroup renaming by Paul Menage [EMAIL PROTECTED])
This patch is inspired by the discussion at
http://lkml.org/lkml/2007/4/11/187 and implements per cgroup statistics
as suggested by Andrew Morton in http://lkml.org/lkml/2007/4/11/263. The
patch
From: Balbir Singh [EMAIL PROTECTED]
(container-cgroup renaming by Paul Menage [EMAIL PROTECTED])
Nick Piggin pointed out that swap cache and page cache addition routines
could be called from non GFP_KERNEL contexts. This patch makes the
charging routine aware of the gfp context. Charging might
From: Balbir Singh [EMAIL PROTECTED]
(container-cgroup renaming by Paul Menage [EMAIL PROTECTED])
Choose if we want cached pages to be accounted or not. By default both are
accounted for. A new set of tunables are added.
echo -n 1 mem_control_type
switches the accounting to account for only
201 - 300 of 663 matches
Mail list logo
