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, 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
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 unsubscr
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 th
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 i
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 fol
-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
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
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 mor
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 ti
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 th
parse warnings 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 PROT
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 kn
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
> http://lkm
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 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.
>
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
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 als
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 a
"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
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 http://vger.kernel.org/majordomo-in
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
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()
>
>
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, prob
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
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 group
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
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 infe
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
"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: cgrou
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
> > ov
[ 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
> >
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 unsu
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 r
From: Paul Menage <[EMAIL PROTECTED]>
Add a new mount() flag, MS_BIND_FLAGS.
MS_BIND_FLAGS indicates that a bind mount should take its per-mount flags
from the arguments passed to mount() rather than from the source
mountpoint.
This flag allows you to create a bind mount with the desir
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 retu
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 o
On Jan 31, 2008 11:58 PM, Peter Zijlstra <[EMAIL PROTECTED]> wrote:
> > Is there a restriction in CFS that stops a given group from
> > simultaneously holding tasks and sub-groups? If so, couldn't we change
> > CFS to make it possible rather than enforcing awkward restrictions on
> > cgroups?
>
> I
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 arg
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/cpu
, i.e.
> the pid as it is seen from inside 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(
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
>
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 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 th
On Dec 1, 2007 10:36 AM, Rik van Riel <[EMAIL PROTECTED]> wrote:
>
> With the /proc/refaults info, we can measure how much extra
> memory each process group needs, if any.
What's the status of that? It looks as though it would be better than
the "accessed in the last N seconds" metric that we've b
Hi Vatsa,
Thanks, this looks pretty good.
On Nov 30, 2007 4:42 AM, Srivatsa Vaddagiri <[EMAIL PROTECTED]> wrote:
>
> - Removed load average information. I felt it needs more thought (esp
> to deal with SMP and virtualized platforms) and can be added for
> 2.6.25 after
On Nov 29, 2007 6:11 PM, Nick Piggin <[EMAIL PROTECTED]> wrote:
> And also some
> results or even anecdotes of where this is going to be used would be
> interesting...
We want to be able to run multiple isolated jobs on the same machine.
So being able to limit how much memory each job can consume,
On Nov 12, 2007 11:59 PM, Srivatsa Vaddagiri <[EMAIL PROTECTED]> wrote:
>
> Thinking of it more, this requirement to "group tasks for only accounting
> purpose" may be required for other resources (mem, io, network etc) as well?
> Should we have a generic accounting controller which can provide the
On Nov 12, 2007 11:48 PM, Srivatsa Vaddagiri <[EMAIL PROTECTED]> wrote:
>
> Regarding your concern about tracking cpu usage in different ways, it
> could be mitigated if we have cpuacct controller track usage as per
> information present in a task's sched entity structure
> (tsk->se.sum_exec_runtim
On Nov 12, 2007 11:29 PM, Balbir Singh <[EMAIL PROTECTED]> wrote:
>
> I think it's a good hack, but not sure about the complexity to implement
> the code. I worry that if the number of tasks increase (say run into
> thousands for one or more groups and a few groups have just a few
> tasks), we'll l
On Nov 12, 2007 11:00 PM, Balbir Singh <[EMAIL PROTECTED]> wrote:
>
> Right now, one of the limitations of the CPU controller is that
> the moment you create another control group, the bandwidth gets
> divided by the default number of shares. We can't create groups
> just for monitoring.
Could we
On Nov 12, 2007 10:00 PM, Srivatsa Vaddagiri <[EMAIL PROTECTED]> wrote:
> On second thoughts, this may be a usefull controller of its own.
> Say I just want to "monitor" usage (for accounting purpose) of a group of
> tasks, but don't want to control their cpu consumption, then cpuacct
> con
Hi Linus,
Please can you revert commit 62d0df64065e7c135d0002f069444fbdfc64768f,
entitled "Task Control Groups: example CPU accounting subsystem" ?
This was originally intended as a simple initial example of how to
create a control groups subsystem; it wasn't intended for mainline,
but I didn't m
file.
>
>
> Signed-off-by: Diego Calleja <[EMAIL PROTECTED]>
(with the addition of akpm's KERN_INFO for cgroup_init_subsys() )
Acked-by: Paul Menage <[EMAIL PROTECTED]>
Paul
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the
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
-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
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
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:
>
>
I suppose it is the
kernel standard.
Acked-by: Paul Menage <[EMAIL PROTECTED]>
>
> ---
>
> This patch applies --after-- Adrian Bunk's patch:
> [2.6 patch] kernel/cgroup.c: remove dead code
>
> kernel/cgroup.c | 15 +--
> 1 file changed, 5 inse
On 10/24/07, Paul Jackson <[EMAIL PROTECTED]> wrote:
> From: Paul Jackson <[EMAIL PROTECTED]>
>
> Simplify the space stripping code in cgroup file write.
>
> Signed-off-by: Paul Jackson <[EMAIL PROTECTED]>
Acked-by: Paul Menage <[EMAIL PROTECTED]>
&g
On 10/24/07, Paul Jackson <[EMAIL PROTECTED]> wrote:
> Paul M wrote:
> > 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?
>
> Perhaps we can simplify this check then, to:
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
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
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
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
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
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:
> > 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
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, 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.
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/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/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, 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
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, 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
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);
> > +
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
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
1 - 100 of 333 matches
Mail list logo
