On 10/23/07, Srivatsa Vaddagiri <[EMAIL PROTECTED]> wrote:
>
> agreed, we need to be reporting idle time in (milli)seconds, although
> the requirement we had was to report it back in percentage. I guess the
> percentage figure can be derived from the raw idle time number.
>
> How about:
>
>
On 10/25/07, Paul Jackson <[EMAIL PROTECTED]> wrote:
> Paul M wrote:
> > Sounds reasonable to me. Is there any kind of compile-time assert
> > macro in the kernel?
>
> Check out the assembly code generated by:
>
> BUG_ON(sizeof(cgrp->root->release_agent_path) < PATH_MAX));
>
> (Hint: you can't
-by: Paul Menage <[EMAIL PROTECTED]>
---
Documentation/cgroups.txt | 22 +++---
kernel/cgroup.c | 36
2 files changed, 35 insertions(+), 23 deletions(-)
Index: container-2.6.23-mm1/kernel/cg
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
Signed-off-by: Paul Menage <[EMAIL PROTECTED]>
---
kernel/sched.c | 36 +++-
1 file changed, 31 inser
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
Signed-off-by: Paul Menage <[EMAIL PROTECTED]>
---
kernel/sched.c | 36 +++-
1 file changed, 31 inser
On 7/20/07, Balbir Singh <[EMAIL PROTECTED]> wrote:
+
+ssize_t res_counter_read(struct res_counter *counter, int member,
+ const char __user *userbuf, size_t nbytes, loff_t *pos)
+{
+ unsigned long *val;
+ char buf[64], *s;
+
+ s = buf;
+ val = res_counter_me
On 7/20/07, Balbir Singh <[EMAIL PROTECTED]> wrote:
+config CONTAINER_MEM_CONT
+ bool "Memory controller for containers"
+ select CONTAINERS
Andrew asked me to not use "select" in Kconfig files due to some
unspecified problems seen in the past, so my latest patchset makes the
subsy
On 7/20/07, Paul Menage <[EMAIL PROTECTED]> wrote:
On 7/20/07, Balbir Singh <[EMAIL PROTECTED]> wrote:
> + mem = mem_container_from_cont(task_container(p,
> + mem_container_subsys_id));
> + css_get(&mem->css);
The c
On 7/20/07, Balbir Singh <[EMAIL PROTECTED]> wrote:
+ mem = mem_container_from_cont(task_container(p,
+ mem_container_subsys_id));
+ css_get(&mem->css);
The container framework won't try to free a subsystem's root container
state, so this isn't
On 7/20/07, Paul Menage <[EMAIL PROTECTED]> wrote:
> + mem = rcu_dereference(mm->mem_container);
> + /*
> +* For every charge from the container, increment reference
> +* count
> +*/
> + css_get(&mem->css);
> +
On 7/20/07, Balbir Singh <[EMAIL PROTECTED]> wrote:
+void __always_inline unlock_meta_page(struct page *page)
+{
+ bit_spin_unlock(PG_metapage, &page->flags);
+}
Maybe add a BUG_ON(!test_bit(PG_metapage, &page->flags)) at least for
development?
+ mem = rcu_dereference(mm->mem_con
On 7/20/07, James Morris <[EMAIL PROTECTED]> wrote:
> + if ((current->euid) && (current->euid != tsk->uid)
> + && (current->euid != tsk->suid)) {
> + put_task_struct(tsk);
> + return -EACCES;
I wonder if we should allow CAP_SYS_
On 7/20/07, Balbir Singh <[EMAIL PROTECTED]> wrote:
-static struct mem_container init_mem_container;
+static ssize_t mem_control_type_read(struct container *cont,
+ struct cftype *cft,
+ struct file *file, char __user *userbuf,
+
On 8/28/07, YAMAMOTO Takashi <[EMAIL PROTECTED]> wrote:
>
> although i have no good idea right now, something which allows
> to move a process with its thread group leader dead would be better.
>
One way I was thinking of approaching this problem was slightly different:
- every mm always has an "
On 8/29/07, Balbir Singh <[EMAIL PROTECTED]> wrote:
>
> Change the interface to use kilobytes instead of pages. Page sizes can vary
> across platforms and configurations. A new strategy routine has been added
> to the resource counters infrastructure to format the data as desired.
>
> Suggested by
On 8/29/07, Balbir Singh <[EMAIL PROTECTED]> wrote:
> >
> > This seems a bit inconsistent - if you write a value to a limit file,
> > then the value that you read back is reduced by a factor of 1024?
> > Having the "(kB)" suffix isn't really a big help to automated
> > middleware.
> >
>
> Why is th
On 8/29/07, Dave Hansen <[EMAIL PROTECTED]> wrote:
> On Thu, 2007-08-30 at 03:34 +0530, Balbir Singh wrote:
> > I've thought about this before. The problem is that a user could
> > set his limit to 1 bytes, but would then see the usage and
> > limit round to the closest page boundary. This can
On 8/15/07, Andrew Morton <[EMAIL PROTECTED]> wrote:
>
> I don't recall what specifically went wrong when we were using select
> in there, but it was pretty ugly.
>
> We're hitting more and more problems with this "select is
> broken"-versus-"depends-on user inferface sucks" problem.
How about if
On 9/2/07, Balbir Singh <[EMAIL PROTECTED]> wrote:
> - s += sprintf(s, "%lu\n", *val);
> + if (read_strategy)
> + s += read_strategy(*val, s);
> + else
> + s += sprintf(s, "%lu\n", *val);
This would be better as %llu
> + tmp = simple_str
On 9/3/07, Balbir Singh <[EMAIL PROTECTED]> wrote:
> Paul Menage wrote:
> > On 9/2/07, Balbir Singh <[EMAIL PROTECTED]> wrote:
> >> - s += sprintf(s, "%lu\n", *val);
> >> + if (read_strategy)
> >> + s += read_s
I'm away from work at the moment and can't investigate fully, but it
looks as though this may be the same one that I mentioned in the
introductory email to the patchset. If so, it's a false positive -
there's a point in the container mount code where we need to lock a
newly-created (and hence guara
On 8/7/07, Peter Zijlstra <[EMAIL PROTECTED]> wrote:
>
> The typical annotation would be using spin_lock_nested/mutex_lock_nested
> with a non-0 nesting level for this one case.
>
OK, I'll look into this when I get back from vacation.
Thanks,
Paul
-
To unsubscribe from this list: send the line "
On 7/26/07, YAMAMOTO Takashi <[EMAIL PROTECTED]> wrote:
> > +Other fields in the container_subsys object include:
>
> > +- hierarchy: an index indicating which hierarchy, if any, this
> > + subsystem is currently attached to. If this is -1, then the
> > + subsystem is not attached to any hierarch
On 7/28/07, Andrew Morton <[EMAIL PROTECTED]> wrote:
> > [] proc_cpuset_show+0x5e/0xb9
> > [] seq_read+0xef/0x266
> > [] vfs_read+0x8e/0x117
> > [] sys_read+0x3d/0x61
> > [] sysenter_past_esp+0x5f/0x99
> > ===
> > INFO: lockdep is turned off.
> > Code: 00 89 d8 83 c4 0c 5b
On 8/15/07, Paul Jackson <[EMAIL PROTECTED]> wrote:
> Lee wrote:
> > [altho' methinks CPUSET should select CONTAINERS rather than
> > depend on it...]
>
> Good point -- what do you think, Paul Menage?
That's how I made the configs originally; akpm asked
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 sinc
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 w
Thanks - this has already been sent to akpm.
Paul
On 10/22/07, Dave Hansen <[EMAIL PROTECTED]> wrote:
>
> I just noticed this in mainline:
>
> kernel/cgroup.c: In function `proc_cgroupstats_show':
> kernel/cgroup.c:2405: warning: unused variable `root'
>
>
> ---
>
> linux-2.6.git-dave/kernel/cgr
These two patches consist of a small cleanup to CFS, and adding a control file
reporting CPU usage in milliseconds in each CGroup directory. They're just
bundled together since the second patch depends slightly on the cleanups in the
first patch.
-
To unsubscribe from this list: send the line
Clean up some CFS CGroup code
- replace "cont" with "cgrp" in a few places in the CFS cgroup code,
- use write_uint rather than write for cpu.shares write function
Signed-off-by: Paul Menage <[EMAIL PROTECTED]>
---
kernel/sched.c | 51 +--
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 &l
On 10/22/07, Srivatsa Vaddagiri <[EMAIL PROTECTED]> wrote:
> On Mon, Oct 22, 2007 at 05:49:39PM -0700, Paul Menage wrote:
> > +static u64 cpu_usage_read(struct cgroup *cgrp, struct cftype *cft)
> > +{
> > + struct task_group *tg = cgroup_tg(cgrp);
> > +
On 10/22/07, Balbir Singh <[EMAIL PROTECTED]> wrote:
>
> I think we also need the notion of load, like we have in cpu_acct.c
Yes, a notion of load would be good - but the "load" calculated by
cpu_acct.c isn't all that useful yet - it's just a total of the CPU
cycles used in the 10 second time inte
are held when cpuset_rt_set_overload() is called?
>
> Questions for Paul Menage:
>
> Does 'tsk' need to be locked for the above task_cs() call?
Cgroups doesn't change the locking rules for accessing a cpuset from a
task - you have to have one of:
- task_lock(task)
- callbac
On 10/22/07, Srivatsa Vaddagiri <[EMAIL PROTECTED]> wrote:
>
> Minor nit: From pov of making this patch series git bisect safe, shouldn't we
> be registering a write_uint() handler in this patch as well?
>
Yes, we should. Sigh. I originally had the cleanup and the new
reporting interface in the sa
On 10/22/07, Paul Menage <[EMAIL PROTECTED]> wrote:
>
> Using cgroup_mutex is certainly possible for now, although more
> heavy-weight than I'd like long term. Using css_get isn't the right
> approach, I think - we shouldn't be able to cause an rmdir to fail due
&
On 10/22/07, Paul Menage <[EMAIL PROTECTED]> wrote:
> On 10/22/07, Srivatsa Vaddagiri <[EMAIL PROTECTED]> wrote:
> >
> > Minor nit: From pov of making this patch series git bisect safe, shouldn't
> > we
> > be registering a write_uint() handler in this
On 10/23/07, Balbir Singh <[EMAIL PROTECTED]> wrote:
>
> Well, most people who care about deletion will use the notify_on_release
> callback and retry.
I'm not convinced this is true. Certainly the userspace approaches
we're developing at Google don't (currently) use notify_on_release.
Paul
-
To
On 10/23/07, Balbir Singh <[EMAIL PROTECTED]> wrote:
>
> Well, without notify_on_release you can never be sure if a new task
> got added to the control group or if someone acquired a reference
> to it. I can't think of a safe way of removing control groups/cpusets
> without using notify_on_release.
subsystem state objects alive until the file
is closed.
The documentation is updated to reflect the changed semantics of
destroy(); additionally the locking comments for destroy() and some
other methods were clarified and decrustified.
Signed-off-by: Paul Menage <[EMAIL PROTEC
On 10/23/07, Srivatsa Vaddagiri <[EMAIL PROTECTED]> wrote:
> > Adds a cpu.usage file to the CFS cgroup that reports CPU usage in
> > milliseconds for that cgroup's tasks
>
> It would be nice to split this into user and sys time at some point.
Sounds reasonable - but does CFS track this?
> We have
On 10/23/07, Jeff Garzik <[EMAIL PROTECTED]> wrote:
> Signed-off-by: Jeff Garzik <[EMAIL PROTECTED]>
Acked-by: Paul Menage <[EMAIL PROTECTED]>
> ---
>
> diff --git a/kernel/cgroup.c b/kernel/cgroup.c
> index 5987dcc..3fe21e1 100644
> --- a/kernel/cgroup.c
On 10/23/07, Srivatsa Vaddagiri <[EMAIL PROTECTED]> wrote:
> > Suppose you have two cgroups that would each want to use, say, 55% of
> > a CPU - technically they should each be regarded as having 45% idle
> > time, but if they run on a the same CPU the chances are that they will
> > both always hav
Clean up some CFS CGroup code
- replace "cont" with "cgrp" in a few places in the CFS cgroup code,
- use write_uint rather than write for cpu.shares write function
Signed-off-by: Paul Menage <[EMAIL PROTECTED]>
---
This is a resend of yesterday's mail with t
I think I'd rather not make this change - if we later changed the size
of release_agent_path[] this could silently fail. Can we get around
the coverity checker somehow?
Paul
On 10/24/07, Adrian Bunk <[EMAIL PROTECTED]> wrote:
> This patch removes dead code spotted by the Coverity checker
> (look
On 10/24/07, Adrian Bunk <[EMAIL PROTECTED]> wrote:
> cgroup_is_releasable() and notify_on_release() should be static,
> not global inline.
>
They seem like they could be usefully static inline - or will the
compiler inline them anyway since they're simple enough?
Paul
-
To unsubscribe from this
On 10/24/07, Adrian Bunk <[EMAIL PROTECTED]> wrote:
> cgroup_is_releasable() and notify_on_release() should be static,
> not global inline.
>
> Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
Acked-by: Paul Menage <[EMAIL PROTECTED]>
>
> ---
>
> kernel
On 10/24/07, Adrian Bunk <[EMAIL PROTECTED]> wrote:
>
> Two questions:
> - Is it really intended to perhaps change release_agent_path[] to have
> less than PATH_MAX size?
I've got no intention to do so currently.
> - If yes, do you want to return -E2BIG for (nbytes >= PATH_MAX) or for
> (nbyt
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 caffeine
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
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 lo
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
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
On 1/15/07, Balbir Singh <[EMAIL PROTECTED]> wrote:
In sched.c, account_user_time() can be called with the task p set to rq->idle.
Since idle tasks do not belong to any container, this was causing a panic in
task_ca() in cpu_acct.c.
How come that didn't cause a problem on x86_64? If this is an
On 1/15/07, Balbir Singh <[EMAIL PROTECTED]> wrote:
While writing/extending the cpuacct container, I found it useful to
know if the container resource group we are controlling is really mounted.
Controllers can try and avoid doing work when not mounted and start
when the subsystem is mounted. Al
On 1/15/07, Christoph Lameter <[EMAIL PROTECTED]> wrote:
This solution may be a bit hokey. I tried other approaches but this
one seemed to be the simplest with the least complications. Maybe someone
else can come up with a better solution?
How about a 64-bit field in struct inode that's used a
On 1/16/07, Christoph Lameter <[EMAIL PROTECTED]> wrote:
On Tue, 16 Jan 2007, Paul Menage wrote:
> On 1/15/07, Christoph Lameter <[EMAIL PROTECTED]> wrote:
> >
> > This solution may be a bit hokey. I tried other approaches but this
> > one seemed to be the simp
This patch provides the RG core and numtasks controller as container
subsystems, intended as an example of how to implement a more complex
resource control system over generic process containers. The changes
to the core involve primarily removing the group management, task
membership and configfs s
This patch implements the BeanCounter resource control abstraction
over generic process containers. It contains the beancounter core
code, plus the numfiles resource counter. It doesn't currently contain
any of the memory tracking code or the code for switching beancounter
context in interrupts.
C
ed
- it's easier to test out e.g. the ResGroups CPU controller in
conjunction with the BeanCounters memory controller
- the additional kernel footprint of any of the competing resource
management systems is substantially reduced, since it doesn't need
to provide process grouping/containment, he
This demonstrates how to use the generic container subsystem for a
simple resource tracker that counts the total CPU time used by all
processes in a container, during the time that they're members of the
container.
Signed-off-by: Paul Menage <[EMAIL PROTECTED]>
---
include/linux
subsystem.
Signed-off-by: Paul Menage <[EMAIL PROTECTED]>
---
Documentation/containers.txt | 229 +++
fs/proc/base.c |7
include/linux/container.h| 96 +++
include/linux/sched.h|5
init/Kconfig |9
init/main.c
On 12/23/06, Herbert Poetzl <[EMAIL PROTECTED]> wrote:
On Fri, Dec 22, 2006 at 06:14:48AM -0800, Paul Menage wrote:
> This patch implements the BeanCounter resource control abstraction
> over generic process containers. It contains the beancounter core
> code, plus the numfiles r
On 12/25/06, Kirill Korotaev <[EMAIL PROTECTED]> wrote:
> also note that certain limits are much more
> complicated than the (very simple) file limits
> and the code will be called at higher frequency
Agree with this. This patch doesn't prove that BCs can be integrated to the
containers infrastru
On 12/30/06, Eric W. Biederman <[EMAIL PROTECTED]> wrote:
Paul Menage <[EMAIL PROTECTED]> writes:
> This patch creates a generic process container system based on (and
> parallel top) the cpusets code. At a coarse level it was created by
> copying kernel/cpuset.c, doing
On 2/20/07, Sam Vilain <[EMAIL PROTECTED]> wrote:
The term "segregated group of processes" is too vague. Segregated for
what? What is the kernel supposed to do with this information?
The generic part of the kernel just keeps track of the fact that
they're segregated (and their children, etc)
On 2/20/07, Eric W. Biederman <[EMAIL PROTECTED]> wrote:
> Sam said "the NSProxy *is* the container". You appear to be planning
> to have some namespaces, possibly not aggregated within the nsproxy
> (pid namespace?) but are you planning to have some higher-level
> "container" object that aggrega
On 2/20/07, Sam Vilain <[EMAIL PROTECTED]> wrote:
I don't necessarily agree with the 'heirarchy' bit. It doesn't have to
be so segregated. But I think we already covered that in this thread.
OK, but it's much easier to use a hierarchical system as a flat system
(just don't create children) t
On 2/20/07, Sam Vilain <[EMAIL PROTECTED]> wrote:
Paul Menage wrote:
>> No. A reverse mapping is not needed and is not interesting.
>>
> ... to you.
>
You're missing the point of Eric's next sentence. If you can achieve
everything you need to achieve and get
On 2/12/07, Paul Jackson <[EMAIL PROTECTED]> wrote:
You'll have a rough time selling me on the idea that some kernel thread
should be waking up every few seconds, grabbing system-wide locks, on a
big honkin NUMA box, for the few times per hour, or less, that a cpuset is
abandoned.
I think it c
On 2/12/07, Cedric Le Goater <[EMAIL PROTECTED]> wrote:
>> +#include
>
> I did have a problem with this include. On s390 it didn't exist so I've
> just been running without it (with no problems). A quick 'find'
> suggests it only exists on x86_64, so I'd expect failures on all other
> arches.
On 2/12/07, Sam Vilain <[EMAIL PROTECTED]> wrote:
I know I'm a bit out of touch, but AIUI the NSProxy *is* the container.
We decided a long time ago that a container was basically just a set of
namespaces, which includes all of the subsystems you mention.
You may have done that, but the CKRM/R
On 2/12/07, Serge E. Hallyn <[EMAIL PROTECTED]> wrote:
Well it's an unfortunate conflict, but I don't see where we have any
standing to make Paul change his terminology :)
I have no huge problem with changing my terminology in the interest of
wider adoption. "Container" seems like an appropri
On 2/12/07, Sam Vilain <[EMAIL PROTECTED]> wrote:
Ask yourself this - what do you need the container structure for so
badly, that virtualising the individual resources does not provide for?
Primarily, that otherwise every module that wants to affect/monitor
behaviour of a group of associated pr
On 2/12/07, Sam Vilain <[EMAIL PROTECTED]> wrote:
Not every module, you just make them on sensible, planned groupings.
The danger is that the "container" group becomes a fallback grouping for
things when people can't be bothered thinking about it properly, and
everything including the kitchen si
On 2/12/07, Srivatsa Vaddagiri <[EMAIL PROTECTED]> wrote:
On Mon, Feb 12, 2007 at 12:15:24AM -0800, [EMAIL PROTECTED] wrote:
> +/*
> + * Call css_get() to hold a reference on the container; following a
> + * return of 0, this container subsystem state object is guaranteed
> + * not to be destroye
On 2/12/07, Srivatsa Vaddagiri <[EMAIL PROTECTED]> wrote:
On Mon, Feb 12, 2007 at 12:15:27AM -0800, [EMAIL PROTECTED] wrote:
> This patch implements the BeanCounter resource control abstraction
> over generic process containers.
Forgive my confusion, but do we really need two-levels of resource
On 2/12/07, Srivatsa Vaddagiri <[EMAIL PROTECTED]> wrote:
On Mon, Feb 12, 2007 at 12:15:22AM -0800, [EMAIL PROTECTED] wrote:
> +void container_fork(struct task_struct *child)
> +{
> + task_lock(current);
Can't this be just rcu_read_lock()?
In this particular patch (which is an almost verb
On 2/12/07, Paul Menage <[EMAIL PROTECTED]> wrote:
reaches zero. RCU is still fine for reading the container_group
pointers, but it's no good for updating them, since by the time you
update it it may no longer be your container_group structure, and may
instead be about to be deleted
On 2/13/07, Pavel Emelianov <[EMAIL PROTECTED]> wrote:
[EMAIL PROTECTED] wrote:
> This patch implements the BeanCounter resource control abstraction
> over generic process containers. It contains the beancounter core
> code, plus the numfiles resource counter. It doesn't currently contain
> any o
On 2/13/07, Pavel Emelianov <[EMAIL PROTECTED]> wrote:
I have implementation that moves arbitrary task :)
Is that the one that calls stop_machine() in order to move a task
around? That seemed a little heavyweight ...
May be we can do context (container-on-task) handling lockless?
What did
On 2/13/07, Srivatsa Vaddagiri <[EMAIL PROTECTED]> wrote:
Well, we already bump up reference count in fork() w/o grabbing those
mutexes don't we? Also if rmdir() sees container->count to be zero, then
it means no task is attached to the container. How will then a function
like bc_file_charge() b
On 2/15/07, Serge E. Hallyn <[EMAIL PROTECTED]> wrote:
>
> config CONTAINERS
> - bool "Container support"
> - help
> - This option will let you create and manage process containers,
> - which can be used to aggregate multiple processes, e.g. for
> - the purposes of reso
On 2/19/07, Andrew Morton <[EMAIL PROTECTED]> wrote:
Alas, I fear this might have quite bad worst-case behaviour. One small
container which is under constant memory pressure will churn the
system-wide LRUs like mad, and will consume rather a lot of system time.
So it's a point at which containe
On 2/19/07, Andrew Morton <[EMAIL PROTECTED]> wrote:
This output is hard to parse and to extend. I'd suggest either two
separate files, or multi-line output:
usage: %lu kB
limit: %lu kB
Two separate files would be the container usage model that I
envisaged, inherited from the way cpusets doe
On 2/19/07, Kirill Korotaev <[EMAIL PROTECTED]> wrote:
>
> I think it's OK for a container to consume lots of system time during
> reclaim, as long as we can account that time to the container involved
> (i.e. if it's done during direct reclaim rather than by something like
> kswapd).
hmm, is it
On 2/19/07, Balbir Singh <[EMAIL PROTECTED]> wrote:
>
> More worrisome is the potential for use-after-free. What prevents the
> pointer at mm->container from referring to freed memory after we're dropped
> the lock?
>
The container cannot be freed unless all tasks holding references to it are
g
On 2/20/07, Eric W. Biederman <[EMAIL PROTECTED]> wrote:
"Paul Menage" <[EMAIL PROTECTED]> writes:
> On 2/12/07, Sam Vilain <[EMAIL PROTECTED]> wrote:
>>
>> I know I'm a bit out of touch, but AIUI the NSProxy *is* the container.
>> We decid
On 12/1/06, Srivatsa Vaddagiri <[EMAIL PROTECTED]> wrote:
This patches fixes various bugs I hit in the recently posted container
patches.
1. If a subsystem registers with fork/exit hook during bootup (much
before rcu is initialized), then the resulting synchronize_rcu() in
container_regist
On 12/1/06, Paul Jackson <[EMAIL PROTECTED]> wrote:
Read the comment in kernel/cpuset.c for the routine cpuset_destroy().
It explains that update_flag() is called where it is (turning off
the cpu_exclusive flag, if it was set), to avoid the calling sequence:
cpuset_destroy->update_flag->update
On 12/8/06, Paul Jackson <[EMAIL PROTECTED]> wrote:
-int __cpuset_zone_allowed(struct zone *z, gfp_t gfp_mask)
+int __cpuset_zone_allowed_softwall(struct zone *z, gfp_t gfp_mask)
{
int node; /* node that zone z is on */
const struct cpuset *cs;/* cu
Hi Serge,
On 1/3/07, Serge E. Hallyn <[EMAIL PROTECTED]> wrote:
From: Serge E. Hallyn <[EMAIL PROTECTED]>
Subject: [RFC] [PATCH 1/1] container: define a namespace container subsystem
Here's a stab at a namespace container subsystem based on
Paul Menage's containers patch, just to experiment wit
On 1/10/07, Balbir Singh <[EMAIL PROTECTED]> wrote:
Paul Menage wrote:
> +/* The set of hierarchies in use. Hierarchy 0 is the "dummy
> + * container", reserved for the subsystems that are otherwise
> + * unattached - it never has more than a single container, and al
On 1/10/07, Balbir Singh <[EMAIL PROTECTED]> wrote:
I have run into a problem running this patch on a powerpc box. Basically,
the machine panics as soon as I mount the container filesystem with
This is a multi-processor system?
My guess is that it's a race in the subsystem API that I've been
On 1/11/07, Balbir Singh <[EMAIL PROTECTED]> wrote:
to 0. To walk the hierarchy, I have no root now since I do not have
any task context. I was wondering if exporting the rootnode or providing
a function to export the rootnode of the mounter hierarchy will make
programming easier.
Ah - I misund
On 1/11/07, Balbir Singh <[EMAIL PROTECTED]> wrote:
I tried something similar, I added an activated field, which is set
to true when the ->create() callback is invoked. That did not help
either, the machine still panic'ed.
I think that marking it active when create() is called may be too soon.
On 1/12/07, Balbir Singh <[EMAIL PROTECTED]> wrote:
I understand that the features are exported to userspace. But from
the userspace POV only the mount options change - right?
The mount options, plus the fact that you can mount different
instances of containerfs with different resource contro
On 11/29/06, Paul Jackson <[EMAIL PROTECTED]> wrote:
Your dynamic scheduler mechanisms appear (from what I can tell after a
brief glance) to be a candidate for being such a controller.
Possibly, if it was some kind of multi-level scheduler - i.e. a
top-level scheduler picks which container to
On 11/29/06, Paul Jackson <[EMAIL PROTECTED]> wrote:
config PROC_PID_CPUSET
bool "Include legacy /proc//cpuset file"
depends on CPUSETS
+ default y if CPUSETS
Sounds very reasonable.
2) I wedged the kernel on the container_lock, doing a removal of a cpuset
using not
101 - 200 of 333 matches
Mail list logo
