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
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:
>
>
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
-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
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
On 7/20/07, Balbir Singh <[EMAIL PROTECTED]> wrote:
+
+ssize_t res_counter_read(struct res_counter *counter, int member,
+ const char __user *userbuf, size_t nbytes, loff_t *pos)
+{
+ unsigned long *val;
+ char buf[64], *s;
+
+ s = buf;
+ val = res_counter_me
On 7/20/07, Balbir Singh <[EMAIL PROTECTED]> wrote:
+config CONTAINER_MEM_CONT
+ bool "Memory controller for containers"
+ select CONTAINERS
Andrew asked me to not use "select" in Kconfig files due to some
unspecified problems seen in the past, so my latest patchset makes the
subsy
On 7/20/07, Paul Menage <[EMAIL PROTECTED]> wrote:
On 7/20/07, Balbir Singh <[EMAIL PROTECTED]> wrote:
> + mem = mem_container_from_cont(task_container(p,
> + mem_container_subsys_id));
> + css_get(&mem->css);
The c
On 7/20/07, Balbir Singh <[EMAIL PROTECTED]> wrote:
+ mem = mem_container_from_cont(task_container(p,
+ mem_container_subsys_id));
+ css_get(&mem->css);
The container framework won't try to free a subsystem's root container
state, so this isn't
On 7/20/07, Paul Menage <[EMAIL PROTECTED]> wrote:
> + mem = rcu_dereference(mm->mem_container);
> + /*
> +* For every charge from the container, increment reference
> +* count
> +*/
> + css_get(&mem->css);
> +
On 7/20/07, Balbir Singh <[EMAIL PROTECTED]> wrote:
+void __always_inline unlock_meta_page(struct page *page)
+{
+ bit_spin_unlock(PG_metapage, &page->flags);
+}
Maybe add a BUG_ON(!test_bit(PG_metapage, &page->flags)) at least for
development?
+ mem = rcu_dereference(mm->mem_con
On 7/20/07, James Morris <[EMAIL PROTECTED]> wrote:
> + if ((current->euid) && (current->euid != tsk->uid)
> + && (current->euid != tsk->suid)) {
> + put_task_struct(tsk);
> + return -EACCES;
I wonder if we should allow CAP_SYS_
On 7/20/07, Balbir Singh <[EMAIL PROTECTED]> wrote:
-static struct mem_container init_mem_container;
+static ssize_t mem_control_type_read(struct container *cont,
+ struct cftype *cft,
+ struct file *file, char __user *userbuf,
+
On 8/28/07, YAMAMOTO Takashi <[EMAIL PROTECTED]> wrote:
>
> although i have no good idea right now, something which allows
> to move a process with its thread group leader dead would be better.
>
One way I was thinking of approaching this problem was slightly different:
- every mm always has an "
On 8/29/07, Balbir Singh <[EMAIL PROTECTED]> wrote:
>
> Change the interface to use kilobytes instead of pages. Page sizes can vary
> across platforms and configurations. A new strategy routine has been added
> to the resource counters infrastructure to format the data as desired.
>
> Suggested by
On 8/29/07, Balbir Singh <[EMAIL PROTECTED]> wrote:
> >
> > This seems a bit inconsistent - if you write a value to a limit file,
> > then the value that you read back is reduced by a factor of 1024?
> > Having the "(kB)" suffix isn't really a big help to automated
> > middleware.
> >
>
> Why is th
On 8/29/07, Dave Hansen <[EMAIL PROTECTED]> wrote:
> On Thu, 2007-08-30 at 03:34 +0530, Balbir Singh wrote:
> > I've thought about this before. The problem is that a user could
> > set his limit to 1 bytes, but would then see the usage and
> > limit round to the closest page boundary. This can
On 8/15/07, Andrew Morton <[EMAIL PROTECTED]> wrote:
>
> I don't recall what specifically went wrong when we were using select
> in there, but it was pretty ugly.
>
> We're hitting more and more problems with this "select is
> broken"-versus-"depends-on user inferface sucks" problem.
How about if
On 9/2/07, Balbir Singh <[EMAIL PROTECTED]> wrote:
> - s += sprintf(s, "%lu\n", *val);
> + if (read_strategy)
> + s += read_strategy(*val, s);
> + else
> + s += sprintf(s, "%lu\n", *val);
This would be better as %llu
> + tmp = simple_str
On 9/3/07, Balbir Singh <[EMAIL PROTECTED]> wrote:
> Paul Menage wrote:
> > On 9/2/07, Balbir Singh <[EMAIL PROTECTED]> wrote:
> >> - s += sprintf(s, "%lu\n", *val);
> >> + if (read_strategy)
> >> + s += read_s
I'm away from work at the moment and can't investigate fully, but it
looks as though this may be the same one that I mentioned in the
introductory email to the patchset. If so, it's a false positive -
there's a point in the container mount code where we need to lock a
newly-created (and hence guara
On 8/7/07, Peter Zijlstra <[EMAIL PROTECTED]> wrote:
>
> The typical annotation would be using spin_lock_nested/mutex_lock_nested
> with a non-0 nesting level for this one case.
>
OK, I'll look into this when I get back from vacation.
Thanks,
Paul
-
To unsubscribe from this list: send the line "
On 7/26/07, YAMAMOTO Takashi <[EMAIL PROTECTED]> wrote:
> > +Other fields in the container_subsys object include:
>
> > +- hierarchy: an index indicating which hierarchy, if any, this
> > + subsystem is currently attached to. If this is -1, then the
> > + subsystem is not attached to any hierarch
On 7/28/07, Andrew Morton <[EMAIL PROTECTED]> wrote:
> > [] proc_cpuset_show+0x5e/0xb9
> > [] seq_read+0xef/0x266
> > [] vfs_read+0x8e/0x117
> > [] sys_read+0x3d/0x61
> > [] sysenter_past_esp+0x5f/0x99
> > ===
> > INFO: lockdep is turned off.
> > Code: 00 89 d8 83 c4 0c 5b
On 8/15/07, Paul Jackson <[EMAIL PROTECTED]> wrote:
> Lee wrote:
> > [altho' methinks CPUSET should select CONTAINERS rather than
> > depend on it...]
>
> Good point -- what do you think, Paul Menage?
That's how I made the configs originally; akpm asked
On 10/17/07, Cedric Le Goater <[EMAIL PROTECTED]> wrote:
> Hello !
>
> While polling the contents of a cgroup task file, I caught the
> following corruption. Is there a known race (and a fix) or should
> I start digging ?
Not a known race, no. Sorry, didn't have time to look at this
yesterday sinc
On 10/17/07, Cedric Le Goater <[EMAIL PROTECTED]> wrote:
> Hello !
>
> While polling the contents of a cgroup task file, I caught the
> following corruption. Is there a known race (and a fix) or should
> I start digging ?
>
> list_add corruption. next->prev should be prev (80a3f338), but w
Thanks - this has already been sent to akpm.
Paul
On 10/22/07, Dave Hansen <[EMAIL PROTECTED]> wrote:
>
> I just noticed this in mainline:
>
> kernel/cgroup.c: In function `proc_cgroupstats_show':
> kernel/cgroup.c:2405: warning: unused variable `root'
>
>
> ---
>
> linux-2.6.git-dave/kernel/cgr
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
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
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);
> > +
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
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, 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
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
&
101 - 200 of 407 matches
Mail list logo
