IOW a /proc namespace coupled to cgroup scope would do what you want.
Now my head hurts..
Mine too. The idea is good, but too broad. Boils down to: How do you
couple them? And none of the methods I thought about seemed to make any
sense.
If we really want to have the values in /proc being opt
(12/11/11 9:45 AM), Glauber Costa wrote:
> There is no reason to have a flags field, and then a separate
> bool field just to indicate if 'none' subsystem were explicitly
> requested.
>
> Make it a flag
>
> Signed-off-by: Glauber Cost
es changed, 3 insertions(+), 3 deletions(-)
Reviewed-by: KOSAKI Motohiro
___
Devel mailing list
Devel@openvz.org
https://openvz.org/mailman/listinfo/devel
> -static int notify_on_release(const struct cgroup *cgrp)
> +static inline int notify_on_release(const struct cgroup *cgrp)
> {
> return test_bit(CGRP_NOTIFY_ON_RELEASE,&cgrp->flags);
> }
>
> -static int clone_children(const struct cgroup *cgrp)
> +static inline int clone_children(const
> Peter Zijlstra wrote:
> > NAK, I really utterly dislike that inatomic argument. The alloc side
> > doesn't function in atomic context either. Please keep the thing
> > symmetric in that regards.
>
> Excuse me. kmalloc(GFP_KERNEL) may sleep (and therefore cannot be used in
> atomic context). Howe
> On Wed, Nov 04, 2009 at 01:25:46PM -0800, Paul Menage wrote:
> > 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
> > >
>
>
> Subject: [RFC][v7][PATCH 9/9]: Document clone2() syscall
>
> This gives a brief overview of the clone2() system call. We should
> eventually describe more details in existing clone(2) man page or in
> a new man page.
>
> Changelog[v7]:
> - Rename clone_with_pids() to clone2()
>
> On Tue, Jul 7, 2009 at 5:56 PM, KAMEZAWA
> Hiroyuki wrote:
> >
> > I know people likes to wait for file descriptor to get notification in
> > these days.
> > Can't we have "event" file descriptor in cgroup layer and make it reusable
> > for
> > other purposes ?
>
> I agree - rather than having
> On Mon, Jul 13, 2009 at 5:16 PM, Vladislav
> Buzov wrote:
> >
> > The following sequence of patches introduce memory usage limit notification
> > capability to the Memory Controller cgroup.
> >
> > This is v3 of the implementation. The major difference between previous
> > version is it is based
> Hi Kamezawa-san,
>
> I have a suggestion for css_id numbering. How about using the same
> numbering scheme as process ID for css_id instead of idr? It prevents
> the same ID from being reused quickly.
> blkio-cgroup can benefit from it. If some pages still have an old ID,
> it can somewhat preve
new
> reference to the user_ns, which we've already put in free_user
> before scheduling remove_user_sysfs_dir().
>
> Reported-by: KOSAKI Motohiro
> Signed-off-by: Serge E. Hallyn
> Acked-by: David Howells
> Tested-by: Ingo Mol
Hi
> On Tue, Feb 10, 2009 at 6:41 AM, KOSAKI Motohiro
> wrote:
> > Hi
> >
> > I periodically test kernel on stress workload.
> > Unfortunately, recent kerenel don't survive >24H.
> >
> > It paniced with following stack.
> > Do you have any
Hi Evgeniy,
> On Mon, Jan 26, 2009 at 11:51:27PM -0800, David Rientjes
> (rient...@google.com) wrote:
> > Yeah, I proposed /dev/mem_notify being made as a client of cgroups there
> > in http://marc.info/?l=linux-kernel&m=123200623628685
> >
> > How do you replace the oom killer's capability of
> On Tue, 27 Jan 2009, KOSAKI Motohiro wrote:
>
> > Confused.
> >
> > As far as I know, people want the method of flexible cache treating.
> > but oom seems less flexible than userland notification.
> >
> > Why do you think notification is bad?
> >
Hi
> > > As Alan Cox suggested/wondered in this thread,
> > > http://lkml.org/lkml/2009/1/12/235 , this is a container group based
> > > approach
> > > to override the oom killer selection without losing all the benefits of
> > > the
> > > current oom killer heuristics and oom_adj interface.
> Hi Balbin,
>
> I am very interested in the memory control of container,
> but I don't know where I can find the patches to push the
> functionalities and how to use the codes via some example
> or use cases.
>
> Could you give me some advices?
mmotm (mm on the moment == latest -mm tree) is her
> > We don't have any motivation of its interface change.
>
> We are seeing problems where we are generating a lot of dirty memory
> from asynchronous background writes while more important traffic is
> operating with DIRECT_IO. The DIRECT_IO traffic will incur high
> latency spikes as the pdflush
> Currently the problem we are hitting is that we cannot specify pdflush
> to have background limits less than 1% of memory. I am currently
> finishing up a patch right now that adds a dirty_ratio_millis
> interface. I hope to submit the patch to LKML by the end of the week.
>
> The idea is that
Hi
>> here's a patch to implement memory.min_usage,
>> which controls the minimum memory usage for a cgroup.
>>
>> it works similarly to mlock;
>> global memory reclamation doesn't reclaim memory from
>> cgroups whose memory usage is below the value.
>> setting it too high is a dangerous operation
Hi balbir-san,
Thank you for nice minutes.
it is very helpful for non invited people (include me).
> 10. Freezer subsystem - The freezer system was discussed briefly. Serge
> mentioned the patches and wanted to collect feedback (if any) on them.
Who use it?
AFAIK the freezer is used by HPC guy
Hi
nice minutes!
below is just my note.
> Control Groups
> ==
>
> 1. Multiphase locking - Paul brought up his multi phase locking design and
> suggested approaches to implementing them. The problem with control groups
> currently is that transactions cannot be atomically committed. I
Hi
fork() is very important for system performance.
I worry about performance regression if this feature isn't used.
Could you mesure spawn benchmark in unixbench?
> Hi Pavel,
>
> Here is the 'hijack' patch that was mentioned during the namespaces
> part of the containers mini-summit. It's a
Hi
> Expand the template sys_checkpoint and sys_restart to be able to dump
> and restore a single task. The task's address space may consist of only
> private, simple vma's - anonymous or file-mapped.
>
> This big patch adds a mechanism to transfer data between kernel or user
> space to and from
CC'ed Paul Jackson
it seems typical ABBA deadlock.
I think cpuset use cgrou_lock() by mistake.
IMHO, cpuset_handle_cpuhp() sholdn't use cgroup_lock() and
shouldn't call rebuild_sched_domains().
-> #1 (cgroup_mutex){--..}:
[] __lock_acquire+0xf45/0x1040
[] lock_acquire+0x98/0xd0
>> Or, if you strongly want to task_limit subsystem use res_counter,
>> I can be working on improve to res_counter performance instead.
>
> I would prefer that as it would help a common cause and avoid
> duplication/maintenance overhead.
okey :)
___
Cont
>> I am going to convert spinlock in task limit cgroup to atomic_t.
>> task limit cgroup has following caractatics.
>>- many write (fork, exit)
>>- few read
>>- fork() is performance sensitive systemcall.
>
> This is true, but I don't see how it can be more performance-sensi
> > Bad performance on the charge/uncharge?
> >
> > The only difference I can see is that res_counter uses
> > spin_lock_irqsave()/spin_unlock_irqrestore(), and you're using plain
> > spin_lock()/spin_unlock().
> >
> > Is the overhead of a pushf/cli/popf really going to matter compared
> > with t
> > > fwiw I think the name sucks!
> > > cgroups are about grouping tasks, so what's a task cgroup?
> >
> > Sorry, my english skill is very low.
> > I hope restrict number of tasks.
> >
> > Do you have any name idea?
>
> Sadly I suck at naming too ;-(
>
> perhaps task_limit controller, or nr_ta
> I guess you didn't notice this comment ? :)
Agghhh, you are right.
sorry.
> >> --- a/kernel/fork.c
> >> > +++ b/kernel/fork.c
> >> > @@ -54,6 +54,7 @@
> >> > #include
> >> > #include
> >> > #include
> >> > +#include
> >> >
> >> > #include
> >> > #include
> >> > @@ -920,6 +921,8 @@
Hi Peter,
> > # mount -t cgroup -o task none /dev/cgroup
> > # mkdir /dev/cgroup/foo
> > # cd /dev/cgroup/foo
> > # ls
> > notify_on_release task.max_tasks task.nr_tasks tasks
> > # echo 100 > task.max_tasks
> > # echo $$ > tasks
> > # fork_bomb 1000 & <- try create 1000 process
> > # pgrep f
Hi
> > v1 -> v2
> > o implement can_attach() and attach() method.
> > o remvoe can_fork member from cgroup_subsys.
> > instead, copy_process() call task_cgroup_can_fork() directly.
> > o fixed dead lock bug.
> > o add Documentation/contoroller/task.txt
> >
>
> I think Documentation/k
Hi Randy,
sorry for so late responce.
REALLY REALLY Thank you for your professional review!
I'll merge it.
> > Index: b/init/Kconfig
> > ===
> > --- a/init/Kconfig
> > +++ b/init/Kconfig
> > @@ -289,6 +289,16 @@ config CGROUP_DEBUG
Hi Paul,
very sorry, late responce.
> > +struct task_cgroup {
> > + struct cgroup_subsys_state css;
> > + /*
> > +* the counter to account for number of thread.
> > +*/
> > + int max_tasks;
> > + int nr_tasks;
> > +
> > + spinlock_t lock;
> > +};
>
>
-t cgroup -o task none /dev/cgroup
# mkdir /dev/cgroup/foo
# cd /dev/cgroup/foo
# ls
notify_on_release task.max_tasks task.nr_tasks tasks
# echo 100 > task.max_tasks
# echo $$ > tasks
# fork_bomb 1000 & <- try create 1000 process
# pgrep fork_bomb | wc -l
98
Signed-off-by: KOSAKI
> > I create new cgroup of number task restriction.
> > Please any comments!
>
> Would it make more sense to implement this as part of an rlimit subsystem,
> which also supports limiting e.g. address space, CPU time, number of open
> files, etc.? If we create one subsystem per resource, I'm afraid
Hi
> Hi Kosaki,
>
> The basic idea of a task-limiting subsystem is good, thanks.
Thanks.
> > -void cgroup_fork(struct task_struct *child)
> > +int cgroup_fork(struct task_struct *child)
> > {
> > + int i;
> > + int ret;
> > +
> > + for (i = 0; i < CGROUP_SUBSYS_COUNT; i++) {
>
> - need_forkexit_callback will be read only after system boot.
> - use_task_css_set_links will be read only after it's set.
>
> And these 2 variables are checked when a new process is forked.
>
> Signed-off-by: Li Zefan <[EMAIL PROTECTED]>
nice :)
A
> You are not handling task migration between groups, i.e.:
># echo $$ > /cgroup/1/tasks
># echo $$ > /cgroup/2/tasks
Oh, nice point out.
Thanks!
> Maybe you need to add this in cgroup_init_subsys():
>
> - need_forkexit_callback |= ss->fork || ss->exit;
> + need_forke
Hi Nishimura-san,
Thanks good point out.
>> +#include
> I don't think it's needed.
> Or, are you planning to implement this feature by using res_counter?
your are right.
my early version use res_counter, but it isn't used currently.
>> + spin_lock(&taskcg->lock);
>> + if (max_tasks <
Hi
Thank you for careful review.
>> + struct task_cgroup *taskcg;
>> +
>> + if ((max_tasks > INT_MAX) ||
>> + (max_tasks < INT_MIN))
>
> It should be < -1 I think.
OK.
I'll fix it at next post.
>> + spin_lock(&taskcg->lock);
>> + if (max_tasks < taskcg->nr_tasks)
>> +
ess
# pgrep fork_bomb|wc -l
98
future work
discussion cgroup guys more.
Signed-off-by: KOSAKI Motohiro <[EMAIL PROTECTED]>
CC: Li Zefan <[EMAIL PROTECTED]>
CC: Paul Menage <[EMAIL PROTECTED]>
---
include/linux/cgroup.h|5 -
inc
>> I'd prefer #ifdef rather than #ifndef.
>>
>> so...
>>
>> #ifdef CONFIG_CGROUP_SWAP_RES_CTLR
>> your definition
>> #else
>> original definition
>> #endif
>>
> OK.
> I'll change it.
Thanks.
>> and vm_swap_full() isn't page granularity operation.
>> this is memory(or swap) cgroup operation.
> One option is to limit the virtual address space usage of the cgroup to ensure
> that swap usage of a cgroup will *not* exceed the specified limit. Along with
> a
> good swap controller, it should provide good control over the cgroup's memory
> usage.
unfortunately, it doesn't works in real wo
> > Have you seen any real world example of this?
>
> At the unsophisticated end, there are lots of (Fortran) HPC applications
> with very large static array declarations but only "use" a small fraction
> of that. Those users know they only need a small fraction and are happy
> to volunteer smal
Hi,
> +#ifndef CONFIG_CGROUP_SWAP_RES_CTLR
> /* Swap 50% full? Release swapcache more aggressively.. */
> -#define vm_swap_full() (nr_swap_pages*2 < total_swap_pages)
> +#define vm_swap_full(page) (nr_swap_pages*2 < total_swap_pages)
> +#else
> +#define vm_swap_full(page) swap_cgroup_vm_swap_full
45 matches
Mail list logo
