On 8/22/07, Balbir Singh [EMAIL PROTECTED] wrote:
Signed-off-by: Balbir Singh [EMAIL PROTECTED]
---
Documentation/memcontrol.txt | 193
+++
1 file changed, 193 insertions(+)
diff -puN /dev/null Documentation/memcontrol.txt
--- /dev/null
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 owning
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 David
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 that? Is it because
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 be
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 me to invert the
dependencies to use depends rather
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
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 10/6/07, David Rientjes [EMAIL PROTECTED] wrote:
It can race with sched_setaffinity(). It has to give up tasklist_lock as
well to call set_cpus_allowed() and can race
cpus_allowed = cpuset_cpus_allowed(p);
cpus_and(new_mask, new_mask, cpus_allowed);
retval =
Paul Jackson wrote:
Paul M, David R, others -- how does this look?
Looks plausible, although as David comments I don't think it handles a
concurrent CPU hotplug/unplug. Also I don't like the idea of doing a
cgroup_lock() across sched_setaffinity() - cgroup_lock() can be held for
relatively
Paul Jackson wrote:
Paul M wrote:
Here's an alternative for consideration, below.
I don't see the alternative -- I just see my patch, with the added
blurbage:
#12 - /usr/local/google/home/menage/kernel9/linux/kernel/cpuset.c
# action=edit type=text
Should I be increasing my
On 10/15/07, Paul Jackson [EMAIL PROTECTED] wrote:
currently against an older kernel
ah .. which older kernel?
2.6.18, but I can do a version against 2.6.23-mm1.
+ if (!retval) {
+ cpus_allowed = cpuset_cpus_allowed(p);
+ if (!cpus_subset(new_mask,
Paul Jackson wrote:
Any chance you could provide a patch that works against cgroups?
Fix cpusets update_cpumask
Cause writes to cpuset cpus file to update cpus_allowed for member
tasks:
- collect batches of tasks under tasklist_lock and then call
set_cpus_allowed() on them outside the
is not intended to have any effect on the generated code;
the output of objdump -d kernel/cgroup.o is unchanged.
Signed-off-by: Paul Menage [EMAIL PROTECTED]
---
kernel/cgroup.c | 496
1 file changed, 248 insertions(+), 248 deletions(-)
Index
On 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 hierarchy, and all
On 7/28/07, Andrew Morton [EMAIL PROTECTED] wrote:
[c0154ad2] proc_cpuset_show+0x5e/0xb9
[c01976b1] seq_read+0xef/0x266
[c0181398] vfs_read+0x8e/0x117
[c01817c9] sys_read+0x3d/0x61
[c010401e] sysenter_past_esp+0x5f/0x99
===
INFO: lockdep is turned off.
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 s/cpuset/container/g
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 with
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
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.
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, hence improving their
chances of getting into the kernel
Signed-off-by: Paul
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/cpu_acct.h | 14
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 |3
kernel
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 resource counter
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
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 all
+ * tasks are part
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
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
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.
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 as
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 simplest with the least complications. Maybe
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;/*
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/pid/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
On 11/29/06, Paul Jackson [EMAIL PROTECTED] wrote:
2) I wedged the kernel on the container_lock, doing a removal of a cpuset
using notify_on_release.
I couldn't reproduce this, with a /sbin/cpuset_release_agent that does:
#!/bin/bash
logger cpuset_release_agent $1
rmdir /dev/cpuset/$1
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
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:
On Feb 7, 2008 12:28 PM, Peter Zijlstra [EMAIL PROTECTED] wrote:
While on the subject, could someone document struct cgroup_subsys.
There's documentation for all the methods in Documentation/cgroup.txt
particular, I've wondered why we have: cgroup_subsys::can_attach() and
not use a return
On Feb 7, 2008 7:37 AM, Pavel Emelyanov [EMAIL PROTECTED] wrote:
The Documentation/cgroups.txt file contains the info on how
to write some controller for cgroups subsystem, but even with
this, one need to write quite a lot of code before developing
the core (or copy-n-paste it from some other
a namespace.
Tune the code accordingly.
Signed-off-by: Pavel Emelyanov [EMAIL PROTECTED]
Acked-by: Paul Menage [EMAIL PROTECTED]
---
kernel/cgroup.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/kernel/cgroup.c b/kernel/cgroup.c
index 2c5cccb..4766bb6
Update comments in cpuset.c
Some of the comments in kernel/cpuset.c were stale following the
transition to control groups; this patch updates them to more closely
match reality.
Signed-off-by: Paul Menage [EMAIL PROTECTED]
Acked-by: Paul Jackson [EMAIL PROTECTED]
---
kernel/cpuset.c | 128
On Jan 30, 2008 6:40 PM, Srivatsa Vaddagiri [EMAIL PROTECTED] wrote:
Here are some questions that arise in this picture:
1. What is the relationship of the task-group in A/tasks with the
task-group in A/a1/tasks? In otherwords do they form siblings
of the same parent A?
I'd argue the
On Jan 18, 2008 7:36 AM, Dhaval Giani [EMAIL PROTECTED] wrote:
On Fri, Jan 18, 2008 at 12:41:03PM +0100, Andrea Righi wrote:
Allow to limit the block I/O bandwidth for specific process containers
(cgroups) imposing additional delays on I/O requests for those processes
that exceed the limits
An approach that we've been experimenting with at Google is much simpler:
- add a network class id subsystem, that lets you associated an id
with each cgroup
- propagate this id to sockets created by that cgroup, and from there
to packets sent/received on that socket
- add a new traffic filter
On Jan 23, 2008 8:48 AM, Andrea Righi [EMAIL PROTECTED] wrote:
1. Implementation of soft limits (limit on contention of resource)
gets harder
Why? do you mean implementing a grace time when the soft-limit is
exceeded? this could be done in cgroup_nl_throttle() introducing 3
additional
files. This will reduce the
chance of future control files clashing with user-provided names.
Signed-off-by: Paul Menage [EMAIL PROTECTED]
---
include/linux/cgroup.h | 21 +++
kernel/cgroup.c| 133 ++---
2 files changed, 148 insertions(+), 6
Update the memory controller to use read_uint for its
limit/usage/failcnt control files, calling the new
res_counter_read_uint() function. This allows the files to show up as
u64 rather than string in the cgroup.api file.
Signed-off-by: Paul Menage [EMAIL PROTECTED]
---
mm/memcontrol.c | 15
This patch adds descriptions to the memory controller API files to
indicate that the usage/limit are in bytes; the names of the control
files can then be simplified to usage/limit.
Also removes the unnecessary mem_force_empty_read() function
Signed-off-by: Paul Menage [EMAIL PROTECTED]
---
mm
This set of patches makes the Control Groups API more structured and
self-describing.
1) Allows control files to be associated with data types such as
u64, string, map, etc. These types show up in a new cgroup.api
file in each cgroup directory, along with a user-readable
string. Files that use
Remove the seq_file boilerplate used to construct the memcontrol stats
map, and instead use the new map representation for cgroup control
files
Signed-off-by: Paul Menage [EMAIL PROTECTED]
---
mm/memcontrol.c | 30 ++
1 file changed, 6 insertions(+), 24 deletions
Adds a new type of supported control file representation, a map from
strings to u64 values.
Signed-off-by: Paul Menage [EMAIL PROTECTED]
---
include/linux/cgroup.h | 19 +++
kernel/cgroup.c| 61 -
2 files changed, 79
rather than string in the cgroup.api file.
Signed-off-by: Paul Menage [EMAIL PROTECTED]
---
kernel/cpuset.c | 158 +---
1 file changed, 83 insertions(+), 75 deletions(-)
Index: cgroupmap-2.6.24-mm1/kernel/cpuset.c
Adds a function for returning the value of a resource counter member,
in a form suitable for use in a cgroup read_uint control file method.
Signed-off-by: Paul Menage [EMAIL PROTECTED]
---
include/linux/res_counter.h |1 +
kernel/res_counter.c|5 +
2 files changed, 6
On Feb 16, 2008 2:07 AM, Balbir Singh [EMAIL PROTECTED] wrote:
Paul Menage wrote:
Hi, Paul,
Do we need to use a cgroup.api file? Why not keep up to date documentation and
get users to use that. I fear that, cgroup.api will not be kept up-to-date,
leading to confusion.
The cgroup.api file
On Feb 16, 2008 1:31 AM, Li Zefan [EMAIL PROTECTED] wrote:
I don't quite catch what you mean. Cgoup does support write-only/read-only
files. For a write-only file, just set .write and .write_uint to be NULL,
similar for a read-only file.
Do I miss something?
I suppose we could infer from
for this.
Signed-off-by: Paul Jackson [EMAIL PROTECTED]
Cc: Paul Menage [EMAIL PROTECTED]
Acked-by: Paul Menage [EMAIL PROTECTED]
---
kernel/cgroup.c |5 +
1 file changed, 1 insertion(+), 4 deletions(-)
--- 2.6.24-mm1.orig/kernel/cgroup.c 2008-02-16 04:20:33.0 -0800
On Feb 17, 2008 9:28 AM, Paul Jackson [EMAIL PROTECTED] wrote:
I'm figuring it would be easiest if you just threw this
little change into your hopper for the bigger changes
you're making
OK, will do.
Paul
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of
On Feb 19, 2008 7:12 AM, Nick Andrew [EMAIL PROTECTED] wrote:
config CGROUPS
bool Control Group support
help
- This option will let you use process cgroup subsystems
- such as Cpusets
+ Control Groups enables processes to be tracked and grouped
+
On Feb 19, 2008 1:57 PM, Paul Jackson [EMAIL PROTECTED] wrote:
Finally, it goes against the one thingie per file (at most, one scalar
vector) that has worked well for us when tried.
Right, I like the idea of keeping things simple. But if you're going
to accept that a vector is useful, then it
On Feb 18, 2008 1:45 AM, Li Zefan [EMAIL PROTECTED] wrote:
But we don't have /proc/proc.api or /sys/sysfs.api ...
True. And /proc is a bit of a mess. Having a similar API file for
sysfs sounds like a good idea to me.
And is it better to describe the debug subsystem too?
Yes, probably,
On Feb 17, 2008 9:49 PM, Li Zefan [EMAIL PROTECTED] wrote:
- replace old name 'cont' with 'cgrp' (Paul Menage did this cleanup for
cgroup.c in commit bd89aabc6761de1c35b154fe6f914a445d301510)
- remove a duplicate declaration of cgroup_path()
Signed-off-by: Li Zefan [EMAIL PROTECTED]
Acked
On Feb 17, 2008 9:49 PM, Li Zefan [EMAIL PROTECTED] wrote:
Cgroup uses unsigned long for subsys bitops, not unsigned long long.
Signed-off-by: Li Zefan [EMAIL PROTECTED]
Acked-by: Paul Menage [EMAIL PROTECTED]
---
kernel/cgroup.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions
On Feb 17, 2008 9:49 PM, Li Zefan [EMAIL PROTECTED] wrote:
opts.release_agent is not kfree()ed in all necessary places.
Signed-off-by: Li Zefan [EMAIL PROTECTED]
Acked-by: Paul Menage [EMAIL PROTECTED]
Good catch, although hopefully something that would be extremely rare
in practice.
Thanks
On Feb 18, 2008 12:39 AM, Li Zefan [EMAIL PROTECTED] wrote:
Misc fixes and updates, make the doc consistent with current
cgroup implementation.
Signed-off-by: Li Zefan [EMAIL PROTECTED]
Acked-by: Paul Menage [EMAIL PROTECTED]
Thanks for these cleanups.
Paul
---
Documentation/cgroups.txt
On Feb 19, 2008 6:54 PM, Nick Andrew [EMAIL PROTECTED] wrote:
config CGROUPS
bool Control Group support
help
Control Groups enables processes to be tracked and grouped
into cgroups. This enables you, for example, to associate
cgroups with
On Feb 17, 2008 9:49 PM, Li Zefan [EMAIL PROTECTED] wrote:
The list head res-tasks gets initialized twice in find_css_set().
Signed-off-by: Li Zefan [EMAIL PROTECTED]
Acked-by: Paul Menage [EMAIL PROTECTED]
---
kernel/cgroup.c |1 -
1 files changed, 0 insertions(+), 1 deletions
On Feb 17, 2008 9:49 PM, Li Zefan [EMAIL PROTECTED] wrote:
fix:
- comments about need_forkexit_callback
- comments about release agent
- typo and comment style, etc.
Signed-off-by: Li Zefan [EMAIL PROTECTED]
---
include/linux/cgroup.h |2 +-
kernel/cgroup.c| 44
rather than string in the cgroup.api file.
Signed-off-by: Paul Menage [EMAIL PROTECTED]
---
kernel/cpuset.c | 156 +---
1 file changed, 82 insertions(+), 74 deletions(-)
Index: cpusets-2.6.25-rc2-mm1/kernel/cpuset.c
Strip all trailing whitespace in cgroup_write_uint
This removes the need for people to remember to pass the -n flag to
echo when writing values to cgroup control files.
Signed-off-by: Paul Menage [EMAIL PROTECTED]
---
kernel/cgroup.c |5 +
1 file changed, 1 insertion(+), 4 deletions
This pair of patches simplifies the cpusets read/write path for the
control files that consist of simple integers.
--
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at
On Feb 19, 2008 9:17 PM, Paul Jackson [EMAIL PROTECTED] wrote:
Perhaps my primary concern with these *.api files was that I did not
understand who or what the critical use or user was; who found this
essential, not just nice to have.
Right now, no-one would find it essential. If/when a
On Feb 19, 2008 9:48 PM, YAMAMOTO Takashi [EMAIL PROTECTED] wrote:
it changes the format from %s %lld to %s: %llu, right?
why?
The colon for consistency with maps in /proc. I think it also makes it
slightly more readable.
For %lld versus %llu - I think that cgroup resource APIs are much more
On Feb 19, 2008 10:14 PM, YAMAMOTO Takashi [EMAIL PROTECTED] wrote:
On Feb 19, 2008 9:48 PM, YAMAMOTO Takashi [EMAIL PROTECTED] wrote:
it changes the format from %s %lld to %s: %llu, right?
why?
The colon for consistency with maps in /proc. I think it also makes it
slightly
2008/2/17 Li Zefan [EMAIL PROTECTED]:
Signed-off-by: Li Zefan [EMAIL PROTECTED]
Acked-by: Paul Menage [EMAIL PROTECTED]
---
kernel/cgroup.c |1 -
1 files changed, 0 insertions(+), 1 deletions(-)
diff --git a/kernel/cgroup.c b/kernel/cgroup.c
index 71cf961..879a056 100644
On Wed, Feb 20, 2008 at 6:14 PM, Li Zefan [EMAIL PROTECTED] wrote:
Paul Menage wrote:
I think that docbook-style function comments need /** at the start of
the comment block.
Yes, I didn't notice it. I revised the patch to fix it.
---
fix:
- comments about
On Thu, Feb 21, 2008 at 8:29 PM, Balbir Singh [EMAIL PROTECTED] wrote:
Looks good, except for the name uint(), can we make it u64(). Integers are 32
bit on both ILP32 and LP64, but we really read/write 64 bit values.
Yes, that's true. But read_uint() is more consistent with all the
other
On Sat, Feb 23, 2008 at 4:09 AM, Paul Jackson [EMAIL PROTECTED] wrote:
A couple of proposals have been made recently by people working Linux
on smaller systems, for improving realtime isolation and memory
pressure handling:
(1) cpu isolation for hard(er) realtime
On Sat, Feb 23, 2008 at 12:04 AM, Andrew Morton
[EMAIL PROTECTED] wrote:
+static int cgroup_map_add(struct cgroup_map_cb *cb, const char *key, u64
value)
+{
+ struct seq_file *sf = cb-state;
+ return seq_printf(sf, %s %llu\n, key, value);
+}
We don't know what type the
moved the affected code,
from kernel/cpuset.c to kernel/cgroup.c, in his patch:
cpusets: update_cpumask revision
Signed-off-by: Paul Jackson [EMAIL PROTECTED]
Acked-by: Paul Menage [EMAIL PROTECTED]
Cc: Harvey Harrison [EMAIL PROTECTED]
Cc: Cliff Wickman [EMAIL PROTECTED
On Sat, Feb 23, 2008 at 12:06 AM, Andrew Morton
[EMAIL PROTECTED] wrote:
It is unclear to me what the relationship is between this and your other
cgroup pseudo-fs changes, but as this is fiddling with a userspace
interface we should get a wiggle on - we don't want to let things like this
On Mon, Feb 4, 2008 at 1:03 PM, Peter Zijlstra [EMAIL PROTECTED] wrote:
+static int cpu_rt_runtime_write(struct cgroup *cgrp, struct cftype *cft,
+ struct file *file,
+ const char __user *userbuf,
+
On Sat, Feb 23, 2008 at 11:57 AM, Peter Zijlstra [EMAIL PROTECTED] wrote:
If so, could we avoid that problem by using 0 rather than -1 as the
unlimited value? It looks from what I've read in the Documentation
changes as though 0 isn't really a meaningful value.
0 means no time, quite
On Sat, Feb 23, 2008 at 12:26 PM, Peter Zijlstra [EMAIL PROTECTED] wrote:
In that case I guess I'll have to add signed versions of the
read_uint/write_uint methods.
Yes, I looked at that, I found the interface somewhat unfortunate, it
would mean growing the struct with two more
On Sat, Feb 23, 2008 at 6:47 PM, Balbir Singh [EMAIL PROTECTED] wrote:
res_counter_read_u64() I'd also want to rename all the other
*read_uint functions/fields to *read_u64 too. Can I do that in a
separate patch?
Sounds sensible to me.
Sure, fair enough.
Actually, since
]
Acked-by: Paul Menage [EMAIL PROTECTED]
Yes, I guess it makes sense to follow the original cpusets behaviour.
I think that got lost when the notify-on-release functionality was
temporarily removed during cgroups development.
---
kernel/cgroup.c |4 +++-
1 files changed, 3 insertions
On Mon, Feb 25, 2008 at 3:55 AM, Balbir Singh [EMAIL PROTECTED] wrote:
A boot option for the memory controller was discussed on lkml. It is a good
idea to add it, since it saves memory for people who want to turn off the
memory controller.
By default the option is on for the following
On Mon, Feb 25, 2008 at 9:18 AM, Balbir Singh [EMAIL PROTECTED] wrote:
I thought about it, but it did not work out all that well. The reason being,
that the memory controller is called in from places besides cgroup.
mem_cgroup_charge_common() for example is called from several places in mm.
I'll send out a prototype for comment.
Something like the patch below. The effects of cgroup_disable=foo are:
- foo doesn't show up in /proc/cgroups
- foo isn't auto-mounted if you mount all cgroups in a single hierarchy
- foo isn't visible as an individually mountable subsystem
As a result
On Mon, Feb 25, 2008 at 7:23 PM, Li Zefan [EMAIL PROTECTED] wrote:
Should those pathces be rebased againt 2.6.25-rc3 ?
No, because they're against 2.6.25-rc2-mm1, which is already has (I
think) any of the new bits in 2.6.25-rc3 that would be affected by
these patches.
Paul
--
To unsubscribe
On Mon, Feb 25, 2008 at 7:01 PM, Li Zefan [EMAIL PROTECTED] wrote:
- foo doesn't show up in /proc/cgroups
Or we can print out the disable flag, maybe this will be better?
Because we can distinguish from disabled and not compiled in from
/proc/cgroups.
Certainly possible, if people
On Mon, Jan 7, 2013 at 5:31 PM, Li Zefan lize...@huawei.com wrote:
I don't think Paul's still maintaining cpusets. Normally it's Andrew
that picks up cpuset patches. It's fine you route it through cgroup
tree.
Yes, I'm sorry - I should have handed on cpusets at the time I had to
hand on
On 7/10/07, Srivatsa Vaddagiri [EMAIL PROTECTED] wrote:
Container stuff. Hold, I guess. I was expecting updates from Paul.
Paul,
Are you working on a new version? I thought it was mostly ready
for mainline.
There are definitely some big changes that I want to make internally
to
On 7/10/07, Andrew Morton [EMAIL PROTECTED] wrote:
Andrew, how about we merge enough of the container framework to
support CFS? Bits we could leave out for now include container_clone()
support and the nsproxy subsystem, fork/exit callback hooks, and
possibly leave cpusets alone for now
On 7/10/07, Andrew Morton [EMAIL PROTECTED] wrote:
I'm inclined to take the cautious route here - I don't think people will be
dying for the CFS thingy (which I didn't even know about?) in .23, and it's
rather a lot of infrastructure to add for a CPU scheduler configurator
Selecting the
On 6/7/07, Balbir Singh [EMAIL PROTECTED] wrote:
this needs tasklist_lock?
rcu_read_lock() should be fine. From Eric's patch at
2.6.17-mm2 - proc-remove-tasklist_lock-from-proc_pid_readdir.patch
The patch mentions that We don't need the tasklist_lock to safely
iterate through processes
On 6/8/07, Serge E. Hallyn [EMAIL PROTECTED] wrote:
The problem is container_clone() doesn't call -create explicitly, it
does vfs_mkdir. So we have no real way of passing in clone_task.
Good point.
Looking at vfs_mkdir(), it's pretty simple, and really the only bits
that apply to
On 6/8/07, Serge E. Hallyn [EMAIL PROTECTED] wrote:
Anyway the patch I sent is simple enough, and if users end up demanding
the ability to better deal with exclusive cpusets, the patch will be
simple enough to extend by changing cpuset_auto_setup(), so let's
stick with that patch since it's
201 - 300 of 663 matches
Mail list logo
