On Fri, Dec 16, 2011 at 4:29 AM, Glauber Costa glom...@parallels.com wrote
diff --git a/kernel/cgroup.c b/kernel/cgroup.c
index 1fd7867..e894a4f 100644
--- a/kernel/cgroup.c
+++ b/kernel/cgroup.c
@@ -1211,9 +1211,9 @@ static int parse_cgroupfs_options(char *data, struct
cgroup_sb_opts
On Thu, Feb 17, 2011 at 5:31 AM, Max Kellermann m...@cm4all.com wrote:
Can limit the number of fork()/clone() calls in a cgroup. It is
useful as a safeguard against fork bombs.
I'd be inclined to simplify this a bit - avoid impacting the fork()
path twice, with cgroup_fork_pre_fork() and
On Mon, Jan 24, 2011 at 1:05 PM, Andrew Morton
a...@linux-foundation.org wrote:
Risky. sched.h doesn't include rwsem.h.
We could make it do so, but almost every compilation unit in the kernel
includes sched.h. It would be nicer to make the kernel build
finer-grained, rather than
On Wed, Feb 9, 2011 at 5:02 PM, KAMEZAWA Hiroyuki
kamezawa.hir...@jp.fujitsu.com wrote:
So, I think it's ok to have 'procs' interface for cgroup if
overhead/impact of patch is not heavy.
Agreed - it's definitely an operation that comes up as either
confusing or annoying for users, depending
On Wed, Feb 9, 2011 at 3:10 PM, Andrew Morton a...@linux-foundation.org wrote:
On Mon, 7 Feb 2011 20:35:42 -0500
Ben Blum bb...@andrew.cmu.edu wrote:
On Sun, Dec 26, 2010 at 07:09:19AM -0500, Ben Blum wrote:
On Fri, Dec 24, 2010 at 03:22:26AM -0500, Ben Blum wrote:
On Wed, Aug 11, 2010 at
On Thu, Feb 3, 2011 at 9:51 AM, Jacob Pan jacob.jun@linux.intel.com wrote:
I think this logic defeats the purpose of having timer_slack
subsystem in the first place. IMHO, the original intention was to have
grouping effect of tasks in the cgroup.
You can get the semantics you want by just
On Wed, Feb 2, 2011 at 12:47 PM, Kirill A. Shutsemov
kir...@shutemov.name wrote:
From: Kirill A. Shutemov kir...@shutemov.name
Signed-off-by: Kirill A. Shutemov kir...@shutemov.name
Acked-by: Paul Menage men...@google.com
---
kernel/cgroup.c | 3 +++
1 files changed, 3 insertions(+), 0
On Wed, Feb 2, 2011 at 12:47 PM, Kirill A. Shutsemov
kir...@shutemov.name wrote:
From: Kirill A. Shutemov kir...@shutemov.name
Provides a way of tasks grouping by timer slack value. Introduces per
cgroup max and min timer slack value. When a task attaches to a cgroup,
its timer slack value
On Thu, Jan 27, 2011 at 5:17 PM, Bryan Huntsman bry...@codeaurora.org wrote:
Tested-by: Mike Bohan mbo...@codeaurora.org
I'm responding on Mike's behalf and adding him to this thread. This
patch improves launch time of a test app from ~700ms to ~250ms on MSM,
with much lower variance across
On Sun, Dec 26, 2010 at 4:09 AM, Ben Blum bb...@andrew.cmu.edu wrote:
(...please include patches inline...)
Reviewed-by: Paul Menage men...@google.com
Thanks,
Paul
___
Containers mailing list
contain...@lists.linux-foundation.org
https://lists.linux
Hi Ben,
Finally finding a moment to actually look at these patches. Sorry it's
been a while. Can you send the patches inline rather than as
attachments in future?
Reviewed-by: Paul Menage men...@google.com
This patch looks fine, although I think that freezer_can_attach_task()
could
On Thu, Dec 16, 2010 at 5:12 PM, Colin Cross ccr...@android.com wrote:
No, if you add a new process to the group while check_for_release, the
bit could get set by the add for the new process, then cleared by the
concurrently running check_for_release.
OK, so we need the semantics that
On Thu, Dec 2, 2010 at 7:07 PM, Colin Cross ccr...@android.com wrote:
Not in one case - if we create a new cgroup and try to move a thread
into it, but the thread is exiting as we move it, we'll call
put_css_set() on the new css_set, which will drop the refcount on the
target cgroup back to 0.
Ping akpm?
On Fri, Oct 8, 2010 at 2:57 PM, Paul Menage men...@google.com wrote:
Hi Andrew,
Do you see any road-blockers for including this patch set in -mm ?
Thanks,
Paul
On Tue, Aug 24, 2010 at 11:08 AM, Paul Menage men...@google.com wrote:
On Tue, Aug 10, 2010 at 10:48 PM, Ben Blum bb
On Thu, Dec 2, 2010 at 12:45 PM, jacob pan
jacob.jun@linux.intel.com wrote:
I guess timer_slack_ns alone cannot qualify for a new subsystem,
I think that it's providing a sufficiently different control from
existing subsystems that making it a separate subsystem is reasonable.
The cpuset
When multiple hierarchies are mounted a task will be in one cgroup on
each hierarchy - which cgroup's timer_slack_ns value should be used
for it?
This doesn't belong in the generic cgroups framework. It sounds like
it's something that should be its own subsystem, or else part of
something like
On Tue, Nov 23, 2010 at 6:06 PM, Li Zefan l...@cn.fujitsu.com wrote:
If we do this, it's not anymore safe to use get_css_set(), which just
increments the refcount without checking if it's zero.
I don't believe that it's currently safe to use get_css_set() on a
zero-refcount css_set anyway - a
On Tue, Nov 23, 2010 at 9:37 PM, Colin Cross ccr...@android.com wrote:
@@ -364,12 +372,8 @@ static void __put_css_set(struct css_set *cg, int
taskexit)
struct cgroup *cgrp = link-cgrp;
list_del(link-cg_link_list);
list_del(link-cgrp_link_list);
-
On Wed, Nov 24, 2010 at 4:11 PM, Colin Cross ccr...@android.com wrote:
We seem to have lost some notify_on_release() checks - maybe move that
to check_for_release()?
check_for_release immediately calls cgroup_is_releasable, which checks
for the same bit as notify_on_release. There's no need
On Sun, Nov 21, 2010 at 8:06 PM, Colin Cross ccr...@android.com wrote:
The synchronize_rcu call in cgroup_attach_task can be very
expensive. All fastpath accesses to task-cgroups that expect
task-cgroups not to change already use task_lock() or
cgroup_lock() to protect against updates, and,
On Sun, Nov 7, 2010 at 9:23 PM, Li Zefan l...@cn.fujitsu.com wrote:
bool active;
bool disabled;
...
?
With alignment 5-8 bool values == 8 bytes in 64-bit machine, compared to
4 bytes with the approach this patch takes.
I meant specifying it as:
bool active:1;
bool disabled:1;
i.e.
On Tue, Nov 9, 2010 at 4:52 PM, Li Zefan l...@cn.fujitsu.com wrote:
bool active:1;
bool disabled:1;
It won't compile, but unsigned char active:1 will do. ;)
Are you sure? I don't have a buildable kernel tree at the moment, but
the following fragment compiled fine for me (with gcc 4.4.3):
On Tue, Nov 9, 2010 at 6:06 PM, Li Zefan l...@cn.fujitsu.com wrote:
That said, I'll happily drop this patch. It just came to me when I
started to add new bool values to the structure. Or if you prefer
bool xxx:1 or just bool xxx, I can do that.
bool xxx:1 is fine with me - I think it's worth
On Sat, Oct 30, 2010 at 2:35 PM, Jesper Juhl j...@chaosbits.net wrote:
Hi,
We can avoid doing a memset in swap_cgroup_swapon() by using vzalloc().
Signed-off-by: Jesper Juhl j...@chaosbits.net
Acked-by: Paul Menage men...@google.com
___
Containers
On Thu, Oct 28, 2010 at 8:44 AM, Tommaso Cucinotta
tommaso.cucino...@sssup.it wrote:
a) why doesn't a cgroup object directly point to a css_set one, but to a
list of them (via cg_cgroup_list elements) ?
Each task is in one cgroup per mounted hierarchy. There's no
requirement that different
On Sun, Oct 24, 2010 at 6:07 PM, Li Zefan l...@cn.fujitsu.com wrote:
Paul had a patch to allow some subsystems to be added to multi-hierarchies,
which may help.
I more or less dropped it since I couldn't see a big use for it - all
the examples I had were more easily implemented as basic cgroup
On Fri, Oct 22, 2010 at 1:09 AM, Li Zefan l...@cn.fujitsu.com wrote:
On x86_32, sizeof(struct cgroup_subsys) shrinks from 276 bytes
to 264.
Signed-off-by: Li Zefan l...@cn.fujitsu.com
Acked-by: Paul Menage men...@google.com
Maybe use bool here?
Paul
---
include/linux/cgroup.h | 10
On Fri, Oct 22, 2010 at 1:09 AM, Li Zefan l...@cn.fujitsu.com wrote:
+ /*
+ * Indicate if this subsystem can be bound/unbound to/from a cgroup
+ * hierarchy which has child cgroups.
+ */
+ unsigned int can_bind:1;
Maybe call this bindable?
Basic idea looks
On Fri, Oct 22, 2010 at 2:38 PM, Matt Helsley matth...@us.ibm.com wrote:
+ *
+ * The iterating order is: a1, a2, b1, c1, c2, a3. So a parent will be
+ * processed before its children.
+ */
You could just say it's a depth-first walk except we process the parent before
its children.
The
On Fri, Oct 22, 2010 at 1:10 AM, Li Zefan l...@cn.fujitsu.com wrote:
- for_each_set_bit(i, added_bits, CGROUP_SUBSYS_COUNT)
- cg-subsys[i] = cgrp-subsys[i];
+ for_each_set_bit(i, bits, CGROUP_SUBSYS_COUNT) {
+ if (add)
+
Maybe re-title this patch to BUG() if a bindable subsystem calls css_get() ?
Paul
On Fri, Oct 22, 2010 at 1:12 AM, Li Zefan l...@cn.fujitsu.com wrote:
For now bindable subsystems should not use css_get/put(), so warn
on this misuse.
Signed-off-by: Li Zefan l...@cn.fujitsu.com
---
On Fri, Oct 22, 2010 at 2:46 PM, Matt Helsley matth...@us.ibm.com wrote:
Alternately you could split the bind/unbind op function pointers
and get rid of the boolean argument. Then just don't fill in the
freezer's unbind op and refuse to unbind subsystems that lack
the unbind op. That seems a
Called when a cgroup subsystem is rebound to a different hierarchy
-and root cgroup. Currently this will only involve movement between
-the default hierarchy (which never has sub-cgroups) and a hierarchy
-that is being created/destroyed (and hence has no sub-cgroups).
+and root cgroup. For
On Thu, Oct 28, 2010 at 5:13 PM, Paul Menage men...@google.com wrote:
Also, post_clone() doesn't get called when creating the css hierarchy
during binding.
Oops, ignore that - I noticed that it does.
Paul
___
Containers mailing list
contain
On Tue, Oct 19, 2010 at 6:12 PM, Stephen Hemminger
shemmin...@vyatta.com wrote:
Where is it stored in an array?
~/kernel/linux-2.6$ git grep debug_subsys
kernel/cgroup.c: kfree(cont-subsys[debug_subsys_id]);
kernel/cgroup.c:struct cgroup_subsys debug_subsys = {
kernel/cgroup.c:
On Tue, Oct 19, 2010 at 6:37 PM, Stephen Hemminger
shemmin...@vyatta.com wrote:
That would work but doesn't because the following is missing
in cgroup_subsys.h!
#ifdef CONFIG_CGROUP_DEBUG
SUBSYS(debug)
#endif
/* */
I see that fragment at line 16 in cgroup_subsys.h (see e.g.
Hi Andrew,
Do you see any road-blockers for including this patch set in -mm ?
Thanks,
Paul
On Tue, Aug 24, 2010 at 11:08 AM, Paul Menage men...@google.com wrote:
On Tue, Aug 10, 2010 at 10:48 PM, Ben Blum bb...@andrew.cmu.edu wrote:
Makes procs file writable to move all threads by tgid
don't think this can happen, because cftype.max_write_len is
PATH_MAX.
Yes, it shouldn't be possible.
But it's pretty unobvious if this is actually true, and the code is
fragile against future changes.
Fair enough - adding the check doesn't hurt anything.
Acked-by: Paul Menage men
On Mon, Sep 27, 2010 at 3:14 AM, Daniel Lezcano daniel.lezc...@free.fr wrote:
Signed-off-by: Daniel Lezcano daniel.lezc...@free.fr
Signed-off-by: Serge E. Hallyn serge.hal...@canonical.com
Cc: Eric W. Biederman ebied...@xmission.com
Cc: Paul Menage men...@google.com
Reviewed-by: Li Zefan l
with EINVAL when
the ns_cgroup subsys is created (a printk will help the user to
understand why the creation fails).
Update the feature remove schedule file with the deprecated ns_cgroup.
Signed-off-by: Daniel Lezcano daniel.lezc...@free.fr
Acked-by: Paul Menage men...@google.com
On Sat, Sep 4, 2010 at 12:31 AM, Daniel Lezcano daniel.lezc...@free.fr wrote:
@@ -229,6 +229,7 @@ inline int cgroup_is_removed(const struct cgroup *cgrp)
/* bits in struct cgroupfs_root flags field */
enum {
ROOT_NOPREFIX, /* mounted subsystems have no named prefix */
+
to be clearer about the new behaviour of the code?
Reviewed-by: Paul Menage men...@google.com
___
Containers mailing list
contain...@lists.linux-foundation.org
https://lists.linux-foundation.org/mailman/listinfo/containers
On Tue, Sep 7, 2010 at 1:23 PM, Daniel Lezcano daniel.lezc...@free.fr wrote:
This bit is awkward - you're storing the original value of the
clone_children flag to report in the mount options, but this isn't
necessarily the current state. Might it be better to not store this
and just report the
On Tue, Sep 7, 2010 at 2:13 PM, Daniel Lezcano daniel.lezc...@free.fr wrote:
The clone_children option behaves like the release-agent mount option no ?
Not quite, since it can be controlled on a per-cgroup basis.
We can mount with a specific release agent and change it at runtime. IMHO it
a specialization of the more
generic new function.
Acked-by: Paul Menage men...@google.com
___
Containers mailing list
contain...@lists.linux-foundation.org
https://lists.linux-foundation.org/mailman/listinfo/containers
Reviewed-by: Paul Menage men...@google.com
___
Containers mailing list
contain...@lists.linux-foundation.org
https://lists.linux-foundation.org/mailman/listinfo/containers
___
Devel mailing list
Devel@openvz.org
https
-writable.patch.
Signed-off-by: Ben Blum bb...@andrew.cmu.edu
Acked-by: Paul Menage men...@google.com
Some of the can_attach() methods could be simplified slightly by
directly returning the result of cgroup_can_attach_per_thread()
Paul
___
Containers mailing
Blum bb...@andrew.cmu.edu
Acked-by: Paul Menage men...@google.com
Paul
___
Containers mailing list
contain...@lists.linux-foundation.org
https://lists.linux-foundation.org/mailman/listinfo/containers
___
Devel
On Fri, Jul 30, 2010 at 4:57 PM, Ben Blum bb...@andrew.cmu.edu wrote:
+ * The threadgroup_fork_lock prevents threads from forking with
+ * CLONE_THREAD while held for writing. Use this for fork-sensitive
+ * threadgroup-wide operations. It's taken for reading in fork.c in
+
On Tue, Aug 3, 2010 at 9:33 PM, Ben Blum bb...@andrew.cmu.edu wrote:
As far as the #ifdef mess goes, it's true that some people don't have
CONFIG_CGROUPS defined. I'd imagine that these are likely to be
embedded systems with a fairly small number of processes and threads
per process. Are there
Cc: Eric W. Biederman ebied...@xmission.com
Cc: Paul Menage men...@google.com
Cc: Jamal Hadi Salim h...@cyberus.ca
Acked-by: Paul Menage men...@google.com
Thanks
---
Documentation/cgroups/cgroups.txt | 2 +-
arch/ia64/configs/generic_defconfig | 1 -
arch/mips/configs
On Mon, Jul 26, 2010 at 2:28 PM, Greg KH gre...@suse.de wrote:
Ok, again, after all of this, who is going to be applying this patch to
their tree for the .36 merge window?
There's no specific cgroups tree - cgroups patches generally go via akpm.
Or should I apply it to my driver-core one?
On Mon, Jul 26, 2010 at 3:05 PM, Greg KH gre...@suse.de wrote:
Wonderful, can I get some acks from the cgroups maintainers? I'll
gladly take it through my tree.
Sure.
Acked-by: Paul Menage men...@google.com
Paul
___
Containers mailing list
contain
On Thu, Jul 22, 2010 at 11:26 AM, Greg KH gre...@suse.de wrote:
We really shouldn't be asking userspace to create new root filesystems.
So follow along with all of the other in-kernel filesystems, and provide
a mount point in sysfs.
For cgroupfs, this should be in /sys/fs/cgroup/ This change
On Thu, Jul 22, 2010 at 11:36 AM, Greg KH gre...@suse.de wrote:
Really? I see systems mounting it at /cgroups/ in the filesystem today.
Sure, it *can* be mounted as a single instance, but you then lose
flexibility. E.g. at Google we want to have a different hierarchy for
the CPU subsystem
On Thu, Jul 22, 2010 at 11:53 AM, Greg KH gre...@suse.de wrote:
If you are using /dev/cgroup/ that's nice, but I don't think that people
are expecting a whole filesystem under a /dev/ subdirectory.
Sure - as I said that's just for historical reasons from when we
migrated from cpusets which
On Thu, Jul 22, 2010 at 12:12 PM, Greg KH gre...@suse.de wrote:
I don't know if we want to encourage that as a mount point, do you?
No.
What are the different names you are giving to your mount points now for
cgroupfs so I can get an idea of how it is used currently?
We don't particularly
On Thu, Jul 22, 2010 at 2:19 PM, Greg KH gre...@suse.de wrote:
Any suggestions from your side?
I'd probably go with Matt's suggestion of /var/run.
Paul
___
Containers mailing list
contain...@lists.linux-foundation.org
On Thu, Jul 22, 2010 at 4:14 PM, Greg KH gre...@suse.de wrote:
Ah, that makes it easier. Paul and Vivek, any objection to this patch
going in now?
Sounds reasonable.
Paul
___
Containers mailing list
contain...@lists.linux-foundation.org
On Wed, Jun 2, 2010 at 7:06 AM, Oleg Nesterov o...@redhat.com wrote:
Yes sure, I understand this part. cgroup_attach_task() correctly checks
PF_EXITING under task_lock(), this protects from the case when this
task has already passed cgroup_exit() which takes this lock too.
Right.
But. This
On Wed, Jun 2, 2010 at 1:20 PM, Oleg Nesterov o...@redhat.com wrote:
Yes sure. The main thread can exit via sys_exit(), this doesn't affect
the thread group. Of course, I am not saying this is common practice,
perhaps no important app does this.
This check has been in cgroups for quite a
On Wed, Jun 2, 2010 at 1:58 PM, Oleg Nesterov o...@redhat.com wrote:
The it that you're proposing to remove is in fact the code that
handles those races.
In that case I confused, and I thought we already agreed that
the PF_EXITING check in attach_task_by_pid() is not strictly needed
for
On Wed, Jun 2, 2010 at 2:38 PM, Oleg Nesterov o...@redhat.com wrote:
cgroup_attach_task() does, and this time PF_EXITING is understandable.
Oh, OK, I was talking about the one in cgroup_attach_task(), which is
called by attach_task_by_pid(), and assumed that you were referring to
the same one.
On Mon, May 31, 2010 at 11:04 AM, Oleg Nesterov o...@redhat.com wrote:
And, forgot to mention, I do not understand the PF_EXITING check in
attach_task_by_pid() (and some others).
At first glance, it buys nothing. PF_EXITING can be set right after
the check.
It can, but it's a benign race.
On Fri, May 28, 2010 at 8:16 AM, Greg Thelen gthe...@google.com wrote:
Signed-off-by: Greg Thelen gthe...@google.com
Acked-by: Paul Menage men...@google.com
Good catch, thanks.
Paul
---
kernel/cgroup.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/kernel
On Tue, May 25, 2010 at 9:53 AM, Michael S. Tsirkin m...@redhat.com wrote:
On Thu, May 20, 2010 at 03:22:15PM -0700, Paul Menage wrote:
On Tue, May 18, 2010 at 5:04 PM, Sridhar Samudrala
samudrala.srid...@gmail.com wrote:
Add a new kernel API to attach a task to current task's cgroup
in all
On Sat, May 8, 2010 at 5:11 PM, Kirill A. Shutemov kir...@shutemov.name wrote:
Introduce struct mem_cgroup_thresholds. It helps to reduce number of
checks of thresholds type (memory or mem+swap).
Signed-off-by: Kirill A. Shutemov kir...@shutemov.name
Acked-by: Paul Menage men...@google.com
I like the principle. I think this patch leaks arrays, though.
I think the sequence:
register;register;unregister;unregister
will leak the array of size 2. Using the notation Ax, Bx, Cx, etc to
represent distinct buffers of size x, we have:
initially: size = 0, thresholds = NULL, spare = NULL
Looks like select_fallback_rq() shouldn't be calling
cpuset_cpus_allowed_locked(), which does a task_lock(), which isn't
IRQ safe. Also, according to its comments that should only be held
with the cpuset callback_mutex held, which seems unlikely from a
softirq handler.
Also, calling
On Mon, Mar 22, 2010 at 3:22 AM, Oleg Nesterov o...@redhat.com wrote:
Please use -signal instead. By the lucky coincidence the lifetime rules
for (greatly misnamed) signal_struct were changed recently in -mm.
With the recent changes, it is always safe to use task-signal. It can't
be changed,
On Sun, Mar 14, 2010 at 8:20 PM, Li Zefan l...@cn.fujitsu.com wrote:
commit e6a1105b (cgroups: subsystem module loading interface)
and commit c50cc752 (sched, cgroups: Fix module export)
result in duplicate including of module.h
Signed-off-by: Li Zefan l...@cn.fujitsu.com
Acked-by: Paul
On Wed, Feb 24, 2010 at 5:31 AM, Kirill A. Shutemov
kir...@shutemov.name wrote:
Actually, we want to fput() cfile, if cfile is not NULL.
Signed-off-by: Kirill A. Shutemov kir...@shutemov.name
Thanks.
Acked-by: Paul Menage men...@google.com
---
kernel/cgroup.c | 2 +-
1 files changed
On Wed, Feb 24, 2010 at 5:28 AM, Kirill A. Shutemov
kir...@shutemov.name wrote:
Using a single goto label to cleanup multi failure paths can
get things wrong quite easily, while multi labels makes the
code cleaner.
I disagree.
It's easer to make mistake on changing code with multi failure
On Tue, Jan 26, 2010 at 12:17 AM, Li Zefan l...@cn.fujitsu.com wrote:
Don't Call get_pid_ns() before we locate/alloc the ns.
Signed-off-by: Li Zefan l...@cn.fujitsu.com
Acked-by: Paul Menage men...@google.com
---
cgroup.c | 8 +++-
1 file changed, 3 insertions(+), 5 deletions
On Thu, Jan 7, 2010 at 4:55 PM, Li Zefan l...@cn.fujitsu.com wrote:
Use multi labels is much better:
I disagree with that - in the absence of a language that can do proper
destructor-based cleanup (i.e. a strictly controlled subset of C++ :-)
) I think it's clearer to have a single failure path
On Mon, Dec 28, 2009 at 3:36 PM, Serge E. Hallyn se...@us.ibm.com wrote:
Quoting Daniel Lezcano (daniel.lezc...@free.fr):
The ns_cgroup is an annoying cgroup at the namespace / cgroup frontier.
True. However, it remains - apart from using smack or SELinux - the
only way to truly lock a
On Wed, Dec 30, 2009 at 7:57 AM, Kirill A. Shutemov
kir...@shutemov.name wrote:
This patch introduces write-only file cgroup.event_control in every
cgroup.
This looks like a nice generic API for doing event notifications - thanks!
Sorry I hadn't had a chance to review it before now, due to
On Mon, Dec 28, 2009 at 3:04 PM, Daniel Lezcano daniel.lezc...@free.fr wrote:
This patch is sent as an answer to a previous thread around the ns_cgroup.
https://lists.linux-foundation.org/pipermail/containers/2009-June/018627.html
It adds a control file 'clone_children' for a cgroup.
This
On Sat, Dec 26, 2009 at 11:33 AM, Kirill A. Shutemov
kir...@shutemov.name wrote:
Add a forgotten item into CONTENTS.
Signed-off-by: Kirill A. Shutemov kir...@shutemov.name
Acked-by: Paul Menage men...@google.com
Thanks,
Paul
---
Documentation/cgroups/cgroups.txt | 1 +
1 files changed
On Tue, Nov 3, 2009 at 10:40 PM, KAMEZAWA Hiroyuki
kamezawa.hir...@jp.fujitsu.com wrote:
Then, to say my own not-seriously-considered idea, I vote for
- /cgroup/[HierarchyName]/
rather than /dev/ or /sys or /opt. This sounds straightforward.
We're using /dev/cgroup (for single mounts) or
On Wed, Nov 4, 2009 at 12:30 PM, Ben Blum bb...@andrew.cmu.edu wrote:
+ init_cgroup_css(css, ss, dummytop);
+ init_css_set.subsys[ss-subsys_id] = dummytop-subsys[ss-subsys_id];
There is a problem here; namely, the init_css_set is supposed to be
immutable after boot. Putting a new
On Wed, Nov 4, 2009 at 9:35 AM, Matt Helsley matth...@us.ibm.com wrote:
If anything, standardizing the mount point(s) will likely provide a false
sense of uniformity and we'll get some bad userspace scripts/tools that
break when nonstandard usage appears. Leaving the mount point undefined
On Mon, Nov 2, 2009 at 5:21 PM, Liu Aleaxander aleaxan...@gmail.com wrote:
Yes, I know it means 'current task', but is this useful to print the
same things with two more files in all the cgroups?
We could just export those files in the root cgroup in the debug hierarchy.
Paul
On Mon, Nov 2, 2009 at 6:03 PM, Li Zefan l...@cn.fujitsu.com wrote:
I doubt the value of module-loadable subsystems. A cgroup subsystem
is usually a kernel resource controller, and normally it needs to
add some hooks in some in-kernel structures and functions, which
makes it impossible to be
On Tue, Oct 27, 2009 at 6:04 PM, Li Zefan l...@cn.fujitsu.com wrote:
I think maybe it's better to store struct file *file to struct cftype,
so we don't need to change write_string(), write(), write_u64()
and write_s64().
We can't do that - multiple open files could be using the same cftype
at
On Tue, Oct 27, 2009 at 11:04 PM, Paul Menage men...@google.com wrote:
On Tue, Oct 27, 2009 at 6:04 PM, Li Zefan l...@cn.fujitsu.com wrote:
I think maybe it's better to store struct file *file to struct cftype,
so we don't need to change write_string(), write(), write_u64()
and write_s64
On Wed, Oct 28, 2009 at 12:24 AM, Matt Helsley matth...@us.ibm.com wrote:
OK, I've done this for write_string(). I named the inline function
cgroup_file_cftype(). It seems that, if we do this for one, then
we should do it for all of the cgroup file io ops. Agreed?
Yes.
Thanks,
Paul
explicitly sorts the results of reading from the
tasks file, and libcg and other users don't appear to care about
ordering.
Signed-off-by: Paul Menage men...@google.com
---
Documentation/cgroups/cgroups.txt | 11 +--
1 files changed, 9 insertions(+), 2 deletions(-)
diff --git
On Thu, Aug 20, 2009 at 2:13 PM, Andrew Mortona...@linux-foundation.org wrote:
s/tsk-sighand/p-sighand
Good catch, thanks. Fixed.
I see no fix anywhere so I did this:
I meant fixed in my tree to go out in the next set of patches.
---
On Thu, Aug 20, 2009 at 9:50 PM, Andrew Mortona...@linux-foundation.org wrote:
I was actually referring to the non-ascii crap in the email.
'twas Paul.
Hmm, so it was. It's sad how much gmail seems like like mangling ascii
patches ...
Paul
___
On Wed, Aug 19, 2009 at 7:37 PM, Li Zefanl...@cn.fujitsu.com wrote:
I come to realize the procs file will make it much harder to convert
vmalloc/kmalloc with a different solution..
Why do you think that?
Paul
___
Containers mailing list
On Wed, Aug 19, 2009 at 7:34 PM, Li Zefanl...@cn.fujitsu.com wrote:
It's sure that reverting this commit makes things easier, but
rebasing this patchset shouldn't be hard. And this doesn't
sound a good reason to revert an innocent commit.
The problem is that Ben's patch set starts with a
On Wed, Aug 19, 2009 at 7:39 PM, Li Zefanl...@cn.fujitsu.com wrote:
+ list_for_each_entry_rcu(p, tsk-thread_group, thread_group) {
+ if (p-sighand) {
+ sighand = tsk-sighand;
s/tsk-sighand/p-sighand
Good catch, thanks. Fixed.
Paul
On Wed, Aug 19, 2009 at 7:54 PM, Li Zefanl...@cn.fujitsu.com wrote:
To avoid showing duplicate threadgroup pids, when dealing with a
thread, you have to check backwards to see if it's group pid
has been printed. Maybe it doesn't add much extra cost with your
proposal, we'll see.
My thought
On Wed, Aug 19, 2009 at 8:11 PM, Li Zefanl...@cn.fujitsu.com wrote:
As you said, the 2 patches differ just in using different var/func
names, so rebasing shouldn't be hard but maybe a bit boring.
Yes - it's a fair amount of work for no real gain.
Paul
On Wed, Aug 19, 2009 at 9:40 PM, Matt Helsleymatth...@us.ibm.com wrote:
On Wed, Aug 19, 2009 at 08:13:59PM -0700, Paul Menage wrote:
On Wed, Aug 19, 2009 at 8:11 PM, Li Zefanl...@cn.fujitsu.com wrote:
As you said, the 2 patches differ just in using different var/func
names, so rebasing
cgroup.procs
1000
$
Signed-off-by: Ben Blum bb...@google.com
Signed-off-by: Paul Menage men...@google.com
---
include/linux/cgroup.h | 22 ++--
kernel/cgroup.c| 278 ++--
2 files changed, 186 insertions(+), 114 deletions(-)
diff --git a/include
a call to
synchronize_rcu() for each task before freeing its old css_set.
Signed-off-by: Ben Blum bb...@google.com
Signed-off-by: Paul Menage men...@google.com
---
include/linux/cgroup.h |3 +++
kernel/cgroup.c|8 +++-
2 files changed, 10 insertions(+), 1 deletions(-)
diff
Revert commit 8827c288feb7810185aa7c2e37537202fc709869
This is in preparation for some clashing cgroups changes that subsume
the original commit's functionaliy.
Signed-off-by: Paul Menage men...@google.com
--
The original commit fixed a pid namespace bug which Ben Blum fixed
independently
Ensures correct concurrent opening/reading of pidlists across pid
namespaces
Adds a read-only procs file similar to tasks that shows only unique
tgids
Paul Menage (1):
Revert commit 8827c288feb7810185aa7c2e37537202fc709869
Documentation/cgroups/cgroups.txt | 25 +
include/linux
1 - 100 of 626 matches
Mail list logo
