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
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
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 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
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
[ 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 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
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
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
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
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
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
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
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| 61 -
2 files chang
"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
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
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
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 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
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 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 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 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 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:
> 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 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 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 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
"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 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
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
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 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 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 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
> http://lkm
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
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: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
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 ti
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 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
-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 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
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
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 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
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, 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 Tue, 31 Oct 2000, Rik van Riel wrote:
>
>Ummm, last I looked Linux held the Specweb99 record;
>by a wide margin...
>
... but since then IBM/Zeus appear to have taken the lead:
http://www.zeus.com/news/articles/001004-001/
http://www.spec.org/osg/web99/results/res2000q3/
But they were using a
In article <[EMAIL PROTECTED]>,
you write:
>
>So how do you reverse a CHROOT?
>
Assuming your process doesn't drop its root privileges, before you do
the initial chroot() you could do:
old_root = open("/", O_RDONLY);
Then later do
fchdir(oldroot);
chroot(".");
But the cleaner and more portabl
sys_swapon() sets SWP_USED in p->flags when it begins to set up a swap
area, and then calls vmalloc() to allocate p->swap_map[], which may
sleep. Most other users of the swap info structures either traverse the
swap list (to which the new swap area hasn't yet been added) or check
SWP_WRITEOK (whi
This is the equivalent patch for Linux 2.2 (prepared against 2.2.19)
for the swapon/procfs race also described in my previous email.
sys_swapon() sets SWP_USED in p->flags when it begins to set up a swap
area, and then calls vmalloc() to allocate p->swap_map[], which may
sleep. Most other users
Currently, dquot_initialize() is a no-op if the inode being initialized
isn't a regular file, directory or symlink. This means that calling
DQUOT_ALLOC_INODE() on a named pipe or AF_UNIX socket has no effect (the
same applies to devices, but this is less likely to be a problem as
random users can
This is the equivalent patch for Linux 2.2 (prepared against 2.2.19) for
the quota loophole described in my previous email.
Currently, dquot_initialize() is a no-op if the inode being initialized
isn't a regular file, directory or symlink. This means that calling
DQUOT_ALLOC_INODE() on a named p
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
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
>
On 10/3/07, Paul Jackson <[EMAIL PROTECTED]> wrote:
>
> - What are these apparent 'exec notifications' that are provided to
>user space that the following mentions - I cannot find any other
>mention of them:
>
> With the ability to classify tasks differently for different
>
On 10/3/07, Paul Jackson <[EMAIL PROTECTED]> wrote:
> From: Paul Jackson <[EMAIL PROTECTED]>
>
> The code in kernel/cgroup.c attach_task() which skips the
> attachment of a task to the group it is already in has to be
> removed. Cpusets depends on reattaching a task to its current
> cpuset, in ord
On 10/3/07, Paul Jackson <[EMAIL PROTECTED]> wrote:
>
> Yes, something in user space has to do it. It's part of the
> kernel-user cpuset API. If you change a cpuset's 'cpus', then
> you have to rewrite each pid in its 'tasks' file back to that
> 'tasks' file in order to get that 'cpus' change to
On 10/3/07, Paul Jackson <[EMAIL PROTECTED]> wrote:
>
> So after changing the 'cpus' of a cpuset, you (something in
> user space) then has to rewrite every pid in that cpusets
> tasks file back to that same tasks file, in order to get the
> change to be applied to each of those tasks, and get them
On 10/3/07, Paul Menage <[EMAIL PROTECTED]> wrote:
>
> What's wrong with, in update_cpumask(), doing a loop across all
> members of the cgroup and updating their cpus_allowed fields?
i.e. something like:
struct cgroup_iter it;
struct task_struct *p;
while ((p = cgroup_iter
On 10/3/07, Paul Jackson <[EMAIL PROTECTED]> wrote:
>
> So far as I can tell, this patch just removes a minor optimization,
It's not minor for any subsystem that has a non-trivial attach() operation.
>
> Any further suggestions, or embarrassing (;) questions?
>
What was wrong with my suggestion
On 10/3/07, Paul Jackson <[EMAIL PROTECTED]> wrote:
>
> But now (correct me if I'm wrong here) cgroups has a per-cgroup task
> list, and the above loop has cost linear in the number of tasks
> actually in the cgroup, plus (unfortunate but necessary and tolerable)
> the cost of taking a global css_s
On 10/3/07, Paul Jackson <[EMAIL PROTECTED]> wrote:
>
> I can't say for sure, but I suspect that if cgroups had always
> been cgroups (short for control groups), then these local 'cont'
> variables would have a different name.
Oh, absolutely. I just refrained from changing them in the rename
since
On 10/4/07, Paul Jackson <[EMAIL PROTECTED]> wrote:
> Paul M,
>
> This snippet from the memory allocation hot path worries me a bit.
>
> Once per memory page allocation, we go through here, needing to peak inside
> the current tasks cpuset to see if it has changed (it's 'mems_generation'
> value do
On 10/2/07, Hugh Dickins <[EMAIL PROTECTED]> wrote:
>
> I accept that full swap control is something you're intending to add
> incrementally later; but the current state doesn't make sense to me.
One comment on swap - ideally it should be a separate subsystem from
the memory controller. That way p
On 10/6/07, Paul Jackson <[EMAIL PROTECTED]> wrote:
>
> This isn't working for me.
>
> The key kernel routine for updating a tasks cpus_allowed
> cannot be called while holding a spinlock.
>
> But the above loop holds a spinlock, css_set_lock, between
> the cgroup_iter_start and the cgroup_iter_end
On 10/6/07, Paul Jackson <[EMAIL PROTECTED]> wrote:
> David wrote:
> > It would probably be better to just save references to the tasks.
> >
> > struct cgroup_iter it;
> > struct task_struct *p, **tasks;
> > int i = 0;
> >
> > cgroup_iter_start(cs->css.cgroup, &it);
> >
On 10/6/07, David Rientjes <[EMAIL PROTECTED]> wrote:
> The getting and putting of the tasks will prevent them from exiting or
> being deallocated prematurely. But this is also a critical section that
> will need to be protected by some mutex so it doesn't race with other
> set_cpus_allowed().
Is
at the beginning and end of passed in masks, this
> doesn't make any visible difference in behaviour. But it's
> one or two hundred kernel text bytes smaller, and easier to
> understand.
>
> Signed-off-by: Paul Jackson <[EMAIL PROTECTED]>
Reviewed-by: Paul Menage <[
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);
> retva
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 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
, 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(
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
In article <[EMAIL PROTECTED]>,
you write:
>
>Safe, perhaps, but also completely useless: there is no way the user
>can set up a functional environment inside the chroot. In other
>words, it's all pain, no gain.
>
It could potentially be useful for a network daemon (e.g. a simplified
anonymous F
>Paul Menage wrote:
>> This could be regarded as the wrong way to solve such a problem, but
>> this kind of bug seems to be occurring often enough on BugTraq that it
>> might be useful if you don't have the resources to do a full security
>> audit on your program (
>
>You need to be root to do mknod. You need to do mknod to create /dev/zero.
>You need /dev/zero to get anywhere near the normal behaviour of the system.
>
Sure, but we're not necessarily looking for a system that behaves
normally in all aspects. The example given was that of a paranoid
network
Some of the comments in and before handle_pte_fault() are obsolete or
misleading:
- page_table_lock has been pushed up into handle_mm_fault() and down
into the various do_xxx_page() handlers.
- mmap_sem protects the adding of vma structures to the vmlist, not
pages to the page tables.
Paul
--
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
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
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
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 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: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 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, 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
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
1 - 100 of 333 matches
Mail list logo
