On Mon, Jan 7, 2013 at 5:31 PM, Li Zefan 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 cgroups. I was only
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 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,
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, 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
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 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
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
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
-by: Li Zefan <[EMAIL PROTECTED]>
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/c
]
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 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
eleasable" file to the cgroup_debug subsystem.
Signed-off-by: Paul Menage <[EMAIL PROTECTED]>
---
include/linux/cgroup.h | 11 +++
kernel/cgroup.c| 23 ---
kernel/cgroup_debug.c | 12 +++-
3 files changed, 22 insertions(+), 24 deletions(-)
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 del
Many of the cpusets control files are simple integer values, which
don't require the overhead of memory allocations for reads and writes.
Move the handlers for these control files into cpuset_read_u64() and
cpuset_write_u64().
Signed-off-by: Paul Menage <[EMAIL PROTECTED]>
---
kernel/cp
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(-)
Index: cgroup-2.6.25-rc2-mm1/kernel/cg
This function isn't needed - a NULL pointer in the cftype read
function will result in the same EINVAL response to userspace.
Signed-off-by: Paul Menage <[EMAIL PROTECTED]>
---
mm/memcontrol.c | 14 --
1 file changed, 14 deletions(-)
Index: cgroup-2.6.25-rc2-mm1/mm/memcon
d the fact that some write_u64()-based control files are now
more forgiving of additional whitespace at the end of their input.
Signed-off-by: Paul Menage <[EMAIL PROTECTED]>
--
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
Adds a function for returning the value of a resource counter member,
in a form suitable for use in a cgroup read_u64 control file method.
Signed-off-by: Paul Menage <[EMAIL PROTECTED]>
---
include/linux/res_counter.h |5 -
kernel/res_counter.c|5 +
2 files chan
Adds a new type of supported control file representation, a map from
strings to u64 values.
Each map entry is printed as a line in a similar format to
/proc/vmstat, i.e. "$key $value\n"
Signed-off-by: Paul Menage <[EMAIL PROTECTED]>
---
include/linux/cgroup.h | 19 +
Several people have justifiably complained that the "_uint" suffix is
inappropriate for functions that handle u64 values, so this patch just
renames all these functions and their users to have the suffic _u64.
Signed-off-by: Paul Menage <[EMAIL PROTECTED]>
---
include/linux
The cgroup debug subsystem isn't generally useful for users. It should default
to "n".
Signed-off-by: Paul Menage <[EMAIL PROTECTED]>
---
init/Kconfig |1 +
1 file changed, 1 insertion(+)
Index: cgroup-2.6.25-rc2-
Update the memory controller to use read_u64 for its
limit/usage/failcnt control files, calling the new
res_counter_read_u64() function.
Signed-off-by: Paul Menage <[EMAIL PROTECTED]>
---
mm/memcontrol.c | 15 ++-
1 file changed, 6 insertions(+), 9 deletions(-)
Index:
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
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
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 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
in cpuset.c
>
> Independently, Cliff Wickman 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]>
>
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
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 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
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
Adds a new type of supported control file representation, a map from
strings to u64 values.
Each map entry is printed as a line in a similar format to
/proc/vmstat, i.e. $key $value\n
Signed-off-by: Paul Menage [EMAIL PROTECTED]
---
include/linux/cgroup.h | 19 +
kernel
()-based control files are now
more forgiving of additional whitespace at the end of their input.
Signed-off-by: Paul Menage [EMAIL PROTECTED]
--
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http
Adds a function for returning the value of a resource counter member,
in a form suitable for use in a cgroup read_u64 control file method.
Signed-off-by: Paul Menage [EMAIL PROTECTED]
---
include/linux/res_counter.h |5 -
kernel/res_counter.c|5 +
2 files changed, 9
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(-)
Index: cgroup-2.6.25-rc2-mm1/kernel/cgroup.c
This function isn't needed - a NULL pointer in the cftype read
function will result in the same EINVAL response to userspace.
Signed-off-by: Paul Menage [EMAIL PROTECTED]
---
mm/memcontrol.c | 14 --
1 file changed, 14 deletions(-)
Index: cgroup-2.6.25-rc2-mm1/mm/memcontrol.c
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
Many of the cpusets control files are simple integer values, which
don't require the overhead of memory allocations for reads and writes.
Move the handlers for these control files into cpuset_read_u64() and
cpuset_write_u64().
Signed-off-by: Paul Menage [EMAIL PROTECTED]
---
kernel/cpuset.c
to the cgroup_debug subsystem.
Signed-off-by: Paul Menage [EMAIL PROTECTED]
---
include/linux/cgroup.h | 11 +++
kernel/cgroup.c| 23 ---
kernel/cgroup_debug.c | 12 +++-
3 files changed, 22 insertions(+), 24 deletions(-)
Index: cgroup-2.6.25-rc2-mm1
The cgroup debug subsystem isn't generally useful for users. It should default
to n.
Signed-off-by: Paul Menage [EMAIL PROTECTED]
---
init/Kconfig |1 +
1 file changed, 1 insertion(+)
Index: cgroup-2.6.25-rc2-mm1/init/Kconfig
Several people have justifiably complained that the _uint suffix is
inappropriate for functions that handle u64 values, so this patch just
renames all these functions and their users to have the suffic _u64.
Signed-off-by: Paul Menage [EMAIL PROTECTED]
---
include/linux/cgroup.h |8
Update the memory controller to use read_u64 for its
limit/usage/failcnt control files, calling the new
res_counter_read_u64() function.
Signed-off-by: Paul Menage [EMAIL PROTECTED]
---
mm/memcontrol.c | 15 ++-
1 file changed, 6 insertions(+), 9 deletions(-)
Index: cgroup-2.6.25
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
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.
>
>
ly
- less boilerplate required in cgroup subsystems
- simplifies transition to a future efficient cgroups binary API
Signed-off-by: Paul Menage <[EMAIL PROTECTED]>
--
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROT
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 del
Adds a new type of supported control file representation, a map from
strings to u64 values.
The map type is printed in a similar format to /proc/meminfo or
/proc//status, i.e. "$key: $value\n"
Signed-off-by: Paul Menage <[EMAIL PROTECTED]>
---
include/linux
that calls res_counter_read_uint().
Signed-off-by: Paul Menage <[EMAIL PROTECTED]>
--
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Ple
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 chan
Update the memory controller to use read_uint for its
limit/usage/failcnt control files, calling the new
res_counter_read_uint() function.
Signed-off-by: Paul Menage <[EMAIL PROTECTED]>
---
mm/memcontrol.c | 15 ++-
1 file changed, 6 insertions(+), 9 deletions(-)
Update the memory controller to use read_uint for its
limit/usage/failcnt control files, calling the new
res_counter_read_uint() function.
Signed-off-by: Paul Menage [EMAIL PROTECTED]
---
mm/memcontrol.c | 15 ++-
1 file changed, 6 insertions(+), 9 deletions(-)
Index: rescounter
that calls res_counter_read_uint().
Signed-off-by: Paul Menage [EMAIL PROTECTED]
--
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http
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
Adds a new type of supported control file representation, a map from
strings to u64 values.
The map type is printed in a similar format to /proc/meminfo or
/proc/pid/status, i.e. $key: $value\n
Signed-off-by: Paul Menage [EMAIL PROTECTED]
---
include/linux/cgroup.h | 19
required in cgroup subsystems
- simplifies transition to a future efficient cgroups binary API
Signed-off-by: Paul Menage [EMAIL PROTECTED]
--
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http
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
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
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/kerne
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 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
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
f-by: Paul Menage <[EMAIL PROTECTED]>
--
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
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 del
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| 59 -
2 files chang
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
t;u64" 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.
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 del
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 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
>
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.
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
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 -
&g
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
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 ++--
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 Ze
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,
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,
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
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
1 - 100 of 811 matches
Mail list logo
