On Fri, Dec 16, 2011 at 4:29 AM, Glauber Costa 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 *opts)
>
On Thu, Feb 17, 2011 at 5:31 AM, Max Kellermann 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 cgroup_fork_fork()
On Wed, Feb 9, 2011 at 3:10 PM, Andrew Morton wrote:
> On Mon, 7 Feb 2011 20:35:42 -0500
> Ben Blum 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 01:46:04AM -0400, Ben Blum wrote:
On Wed, Feb 9, 2011 at 5:02 PM, KAMEZAWA Hiroyuki
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 whether or not they
under
On Mon, Jan 24, 2011 at 1:05 PM, Andrew Morton
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 blunter-grained. Don't be afra
On Thu, Feb 3, 2011 at 9:51 AM, Jacob Pan 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 setting min_slack_ns = ma
On Wed, Feb 2, 2011 at 12:47 PM, Kirill A. Shutsemov
wrote:
> From: Kirill A. Shutemov
>
> 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 adjusts (if needed) to fit min-max ran
On Wed, Feb 2, 2011 at 12:47 PM, Kirill A. Shutsemov
wrote:
> From: Kirill A. Shutemov
>
> Signed-off-by: Kirill A. Shutemov
Acked-by: Paul Menage
> ---
> kernel/cgroup.c | 3 +++
> 1 files changed, 3 insertions(+), 0 deletions(-)
>
> diff --git a/kernel/cg
On Thu, Jan 27, 2011 at 5:17 PM, Bryan Huntsman wrote:
>
> Tested-by: Mike Bohan
>
> 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 tests. We also see UI latency
> imp
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
This patch looks fine, although I think that freezer_can_attach_task()
could be simplified to:
stati
On Sun, Dec 26, 2010 at 4:09 AM, Ben Blum wrote:
> (...please include patches inline...)
Reviewed-by: Paul Menage
Thanks,
Paul
___
Containers mailing list
contain...@lists.linux-foundation.org
https://lists.linux-foundation.org/mailman/listi
On Thu, Dec 16, 2010 at 5:12 PM, Colin Cross 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 whenever the cgroup go
On Thu, Dec 2, 2010 at 7:07 PM, Colin Cross 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. We wouldn'
Ping akpm?
On Fri, Oct 8, 2010 at 2:57 PM, Paul Menage 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 wrote:
>> On Tue, Aug 10, 2010 at 10:48 PM, Ben
On Thu, Dec 2, 2010 at 12:45 PM, jacob pan
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 subsystem definitely doesn't s
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 the
On Wed, Nov 24, 2010 at 4:11 PM, Colin Cross 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 for
> CGRP_
On Tue, Nov 23, 2010 at 9:37 PM, Colin Cross 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 Tue, Nov 23, 2010 at 6:06 PM, Li Zefan 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 css_set starts wi
On Sun, Nov 21, 2010 at 8:06 PM, Colin Cross 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, in cgroup.c,
>
On Tue, Nov 9, 2010 at 6:06 PM, Li Zefan 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 keeping the semant
On Tue, Nov 9, 2010 at 4:52 PM, Li Zefan 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):
struct foo
On Sun, Nov 7, 2010 at 9:23 PM, Li Zefan 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. keeping the bit
On Sat, Oct 30, 2010 at 2:35 PM, Jesper Juhl wrote:
> Hi,
>
> We can avoid doing a memset in swap_cgroup_swapon() by using vzalloc().
>
>
> Signed-off-by: Jesper Juhl
Acked-by: Paul Menage
___
Containers mailing list
cont
On Thu, Oct 28, 2010 at 5:13 PM, Paul Menage 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
conta
>
> 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.
On Fri, Oct 22, 2010 at 2:46 PM, Matt Helsley 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 bit cleaner f
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 wrote:
> For now bindable subsystems should not use css_get/put(), so warn
> on this misuse.
>
> Signed-off-by: Li Zefan
> ---
> include/linux/cgroup.h | 7 +--
>
On Fri, Oct 22, 2010 at 1:10 AM, Li Zefan 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)
> +
On Fri, Oct 22, 2010 at 2:38 PM, Matt Helsley 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 standard term
On Fri, Oct 22, 2010 at 1:09 AM, Li Zefan 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 great, it coul
On Fri, Oct 22, 2010 at 1:09 AM, Li Zefan wrote:
> On x86_32, sizeof(struct cgroup_subsys) shrinks from 276 bytes
> to 264.
>
> Signed-off-by: Li Zefan
Acked-by: Paul Menage
Maybe use "bool" here?
Paul
> ---
> include/linux/cgroup.h | 10 ++
> 1 fi
On Sun, Oct 24, 2010 at 6:07 PM, Li Zefan 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
control files (a
On Thu, Oct 28, 2010 at 8:44 AM, Tommaso Cucinotta
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 hierarchies have isomorphic p
On Tue, Oct 19, 2010 at 6:37 PM, Stephen Hemminger
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.
http://git.kernel.org/?p
On Tue, Oct 19, 2010 at 6:12 PM, Stephen Hemminger
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: .subsys_id =
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 wrote:
> On Tue, Aug 10, 2010 at 10:48 PM, Ben Blum wrote:
>>
>>
>> Makes procs file writable to move all threads by tgid at once
-EINVAL;
>> if (!cgroup_lock_live_group(cgrp))
>> return -ENODEV;
>> strcpy(cgrp->root->release_agent_path, buffer);
>
> I don't think this can happen, because cftype.max_write_len is
> PAT
7;s fail 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
Acked-by: Paul Menage
> ---
>
On Mon, Sep 27, 2010 at 3:14 AM, Daniel Lezcano wrote:
>
> Signed-off-by: Daniel Lezcano
> Signed-off-by: Serge E. Hallyn
> Cc: Eric W. Biederman
> Cc: Paul Menage
> Reviewed-by: Li Zefan
Acked-by: Paul Menage
> ---
> Documentation/cgroups/cgroups.txt | 14 +
On Tue, Sep 7, 2010 at 2:13 PM, Daniel Lezcano 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
> would be better to gi
On Tue, Sep 7, 2010 at 1:23 PM, Daniel Lezcano 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 current value
' blocks in the loop.
Can you fix this description to be clearer about the new behaviour of the code?
Reviewed-by: Paul Menage
___
Containers mailing list
contain...@lists.linux-foundation.org
https://lists.linux-foundation.org/mailman/listinfo/con
On Sat, Sep 4, 2010 at 12:31 AM, Daniel Lezcano 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 */
> + ROOT_CLONE_CHILDREN, /* m
urrent_cg() becomes a specialization of the more
generic new function.
Acked-by: Paul Menage
___
Containers mailing list
contain...@lists.linux-foundation.org
https://lists.linux-foundation.org/mailman/listinfo/containers
_
gid to the 'cgroup.procs'
> file. This current implementation makes use of a per-threadgroup rwsem that's
> taken for reading in the fork() path to prevent newly forking threads within
> the threadgroup from "escaping" while the move is in progre
ork path, under CONFIG_CGROUPS. If another part of
> the kernel later wants to use such a locking mechanism, the CONFIG_CGROUPS
> ifdefs should be changed to a higher-up flag that CGROUPS and the other system
> would both depend on.
>
> This is a pre-patch for cgroup-procs-write.pa
up-procs-writable.patch.
>
> Signed-off-by: Ben Blum
Acked-by: Paul Menage
Some of the can_attach() methods could be simplified slightly by
directly returning the result of cgroup_can_attach_per_thread()
Paul
___
Containers mailing list
contain..
On Tue, Aug 3, 2010 at 9:38 PM, Ben Blum wrote:
>
> rcu_read_lock();
> for_each_subsys(...) {
> can_attach(...);
> }
> rcu_read_unlock();
Sorry, I was misreading this, and didn't notice that it was already
inside an "if (threadgroup) {}" test.
>
> Which forces all can_attaches to not slee
On Tue, Aug 3, 2010 at 9:33 PM, Ben Blum 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 really any s
Hi Ben, Kame,
Sorry for the delay in getting to look at this,
On Tue, Aug 3, 2010 at 6:08 PM, KAMEZAWA Hiroyuki
wrote:
>>
>> for_each_subsys(root, ss) {
>> if (ss->attach)
>> ss->attach(ss, cgrp, oldcgrp, tsk, false);
>> }
>> - set_bit(CGRP_REL
On Fri, Jul 30, 2010 at 4:57 PM, Ben Blum 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
> + * copy_process(
emove CONFIG_CGROUP_NS references.
>
> Signed-off-by: Daniel Lezcano
> Signed-off-by: Serge E. Hallyn
> Cc: Eric W. Biederman
> Cc: Paul Menage
> Cc: Jamal Hadi Salim
Acked-by: Paul Menage
Thanks
> ---
> Documentation/cgroups/cgroups.txt | 2 +-
> arch/ia64/
On Mon, Jul 26, 2010 at 3:05 PM, Greg KH wrote:
>
> Wonderful, can I get some acks from the cgroups maintainers? I'll
> gladly take it through my tree.
Sure.
Acked-by: Paul Menage
Paul
___
Containers mailing list
contain.
On Mon, Jul 26, 2010 at 2:28 PM, Greg KH 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?
>
That sou
On Thu, Jul 22, 2010 at 4:14 PM, Greg KH 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
https://lists.linux-f
On Thu, Jul 22, 2010 at 2:19 PM, Greg KH 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
https://lists.linux-foundation.org/mailman/
On Thu, Jul 22, 2010 at 12:12 PM, Greg KH 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 care about
On Thu, Jul 22, 2010 at 11:53 AM, Greg KH 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 were traditiona
On Thu, Jul 22, 2010 at 11:36 AM, Greg KH 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 (with the tree gr
On Thu, Jul 22, 2010 at 11:26 AM, Greg KH 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 provides
On Wed, Jun 2, 2010 at 2:38 PM, Oleg Nesterov 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. I'd forgotte
On Wed, Jun 2, 2010 at 1:58 PM, Oleg Nesterov 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 correctnes
On Wed, Jun 2, 2010 at 1:20 PM, Oleg Nesterov 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 while and no-o
On Wed, Jun 2, 2010 at 7:06 AM, Oleg Nesterov 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 exactly m
On Mon, May 31, 2010 at 11:04 AM, Oleg Nesterov 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.
Moving a n
On Fri, May 28, 2010 at 8:16 AM, Greg Thelen wrote:
>
> Signed-off-by: Greg Thelen
Acked-by: Paul Menage
Good catch, thanks.
Paul
> ---
> kernel/cgroup.c | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/kernel/cgroup.c b/kernel/cgr
On Tue, May 25, 2010 at 9:53 AM, Michael S. Tsirkin 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
>> wrote:
>> > Add a new kernel API to attach a task to current task's cgroup
>&
On Sat, May 8, 2010 at 5:11 PM, Kirill A. Shutemov 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
Acked-by: Paul Menage
Thanks,
Paul
> ---
> mm/m
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
r
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 cpuset_cpus_al
On Mon, Mar 22, 2010 at 3:22 AM, Oleg Nesterov 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, can't g
On Sun, Mar 14, 2010 at 8:20 PM, Li Zefan 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
Acked-by: Pa
On Wed, Feb 24, 2010 at 5:28 AM, Kirill A. Shutemov
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
> paths, if
On Wed, Feb 24, 2010 at 5:31 AM, Kirill A. Shutemov
wrote:
> Actually, we want to fput() cfile, if cfile is not NULL.
>
> Signed-off-by: Kirill A. Shutemov
Thanks.
Acked-by: Paul Menage
> ---
> kernel/cgroup.c | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-
On Tue, Jan 26, 2010 at 12:17 AM, Li Zefan wrote:
> Don't Call get_pid_ns() before we locate/alloc the ns.
>
> Signed-off-by: Li Zefan
Acked-by: Paul Menage
> ---
> cgroup.c | 8 +++-
> 1 file changed, 3 insertions(+), 5 deletions(-)
>
> --- a/kernel/cgr
On Tue, Jan 26, 2010 at 12:16 AM, Li Zefan wrote:
>
> Signed-off-by: Li Zefan
Acked-by: Paul Menage
> ---
> cgroup.c | 7 +--
> 1 file changed, 5 insertions(+), 2 deletions(-)
>
> --- a/kernel/cgroup.c.orig 2010-01-19 16:37:37.0 +0800
> +++ a/kern
On Thu, Jan 7, 2010 at 4:55 PM, Li Zefan 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 where you can
cle
On Mon, Dec 28, 2009 at 3:04 PM, Daniel Lezcano 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 control file is a b
On Wed, Dec 30, 2009 at 7:57 AM, Kirill A. Shutemov
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 travelling
and day-j
On Mon, Dec 28, 2009 at 3:36 PM, Serge E. Hallyn 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 container into a
On Sat, Dec 26, 2009 at 11:33 AM, Kirill A. Shutemov
wrote:
> Add a forgotten item into CONTENTS.
>
> Signed-off-by: Kirill A. Shutemov
Acked-by: Paul Menage
Thanks,
Paul
> ---
> Documentation/cgroups/cgroups.txt | 1 +
> 1 files changed, 1 insertions(+), 0 deletions(-
On Wed, Nov 4, 2009 at 9:35 AM, Matt Helsley 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
> forces anyone
On Wed, Nov 4, 2009 at 12:30 PM, Ben Blum 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 subsystem state
On Tue, Nov 3, 2009 at 10:40 PM, KAMEZAWA Hiroyuki
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
/dev/cgroup/$hierarchy_name (f
On Mon, Nov 2, 2009 at 6:03 PM, Li Zefan 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 a module.
Not
On Mon, Nov 2, 2009 at 5:21 PM, Liu Aleaxander 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 Wed, Oct 28, 2009 at 12:24 AM, Matt Helsley 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
__
On Tue, Oct 27, 2009 at 11:04 PM, Paul Menage wrote:
> On Tue, Oct 27, 2009 at 6:04 PM, Li Zefan 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()
>>
On Tue, Oct 27, 2009 at 6:04 PM, Li Zefan 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 the same time.
n. The
standard "libcpuset" 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
---
Documentation/cgroups/cgroups.txt | 11 +--
1 files changed, 9 insertions(+), 2
On Thu, Aug 20, 2009 at 9:50 PM, Andrew Morton 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
___
Containers mailing list
On Thu, Aug 20, 2009 at 2:13 PM, Andrew Morton 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.
>
> ---
> a/kernel/cgroup.c~cgroups-add-functionality-to-read-wri
On Wed, Aug 19, 2009 at 9:40 PM, Matt Helsley wrote:
> On Wed, Aug 19, 2009 at 08:13:59PM -0700, Paul Menage wrote:
>> On Wed, Aug 19, 2009 at 8:11 PM, Li Zefan wrote:
>> >
>> > As you said, the 2 patches differ just in using different var/func
>> > names, so re
On Wed, Aug 19, 2009 at 8:11 PM, Li Zefan 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
___
Containe
On Wed, Aug 19, 2009 at 7:54 PM, Li Zefan 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 was to explicitl
On Wed, Aug 19, 2009 at 7:39 PM, Li Zefan 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:34 PM, Li Zefan 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 patch that adds th
On Wed, Aug 19, 2009 at 7:37 PM, Li Zefan 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
contain...@lists.linux-fo
ly) responsible for doing their own
synchronization, since this occurs outside of the critical section
that locks against cloning within a thread group.
Signed-off-by: Ben Blum
Signed-off-by: Paul Menage
---
Documentation/cgroups/cgroups.txt | 13 +
kernel/cgroup.c | 422 +
1 - 100 of 787 matches
Mail list logo
