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
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
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.
>
>
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
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
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
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
like a good idea to me. Thanks 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 dele
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 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
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
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
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 PROTEC
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
ed control 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
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
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 chang
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 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
t;u64" 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-
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
Add linux-fsdevel to the VFS entry in MAINTAINERS
Signed-off-by: Paul Menage <[EMAIL PROTECTED]>
---
MAINTAINERS |1 +
1 file changed, 1 insertion(+)
Index: 2.6.24-mm1-bindflags/MAINTAINERS
===
--- 2.6.24-mm1-bindflag
On Thu, Feb 14, 2008 at 9:31 AM, Miklos Szeredi <[EMAIL PROTECTED]> wrote:
>
> I deliberately not used the MS_* flags, which is currently a messy mix
> of things with totally different meanings.
>
> Does this solve all the issues?
We should add a size parameter either in the mount_params or as
On Thu, Feb 14, 2008 at 8:03 AM, Miklos Szeredi <[EMAIL PROTECTED]> wrote:
> > The "flags" argument could be the same as for regular mount, and
> > contain the mnt_flags - so the extra argument could maybe usefully be
> > a "mnt_flags_mask", to indicate which flags we actually care about
> >
[ cc: linux-fsdevel ]
On Thu, Feb 14, 2008 at 7:22 AM, Paul Menage <[EMAIL PROTECTED]> wrote:
> On Wed, Feb 13, 2008 at 10:02 PM, Christoph Hellwig <[EMAIL PROTECTED]> wrote:
> >
> > I think this concept is reasonable, but I don't think MS_BIND_FLAGS
> > is
On Wed, Feb 13, 2008 at 10:02 PM, Christoph Hellwig <[EMAIL PROTECTED]> wrote:
>
> I think this concept is reasonable, but I don't think MS_BIND_FLAGS
> is a descriptive name for this flag. MS_EXPLICIT_FLAGS might be better
> but still isn't optimal.
>
MS_BIND_FLAGS_OVERRIDE ?
Paul
--
To
On Thu, Feb 14, 2008 at 12:30 AM, Miklos Szeredi <[EMAIL PROTECTED]> wrote:
> > For recursive bind mounts, only the root of the tree being bound
> > inherits the per-mount flags from the mount() arguments; sub-mounts
> > inherit their per-mount flags from the source tree as usual.
>
> This is
On Thu, Feb 14, 2008 at 12:30 AM, Miklos Szeredi [EMAIL PROTECTED] wrote:
For recursive bind mounts, only the root of the tree being bound
inherits the per-mount flags from the mount() arguments; sub-mounts
inherit their per-mount flags from the source tree as usual.
This is rather
On Wed, Feb 13, 2008 at 10:02 PM, Christoph Hellwig [EMAIL PROTECTED] wrote:
I think this concept is reasonable, but I don't think MS_BIND_FLAGS
is a descriptive name for this flag. MS_EXPLICIT_FLAGS might be better
but still isn't optimal.
MS_BIND_FLAGS_OVERRIDE ?
Paul
--
To
1 - 100 of 663 matches
Mail list logo
