Serge,
I've cloned your cryo tree and I'm starting to play with it.
Here are a couple of trivial patches to fix some small issues
with options handling: -l (list) and -f in checkpoint mode.
Still trying to restart the 'sleep' test program.
Benjamin
--
Option -f couldn't be used in conjunction with option -p (for checkpointing).
O_CREAT is missing in the flags passed to open().
Now, we can do:
$ cr -p MYPID -f test.cryo
(I know the coding style is not perfect (long lines, several instructions
on the same line), but it fits with cryo's style
This tiny patch fixes the handling of option -l.
'l' must be added to the getopt() call and the subsequent switch{] if
we don't want to exit too soon.
This makes the following command works:
$ cr -l -t test.cryo
Signed-off-by: Benjamin Thery [EMAIL PROTECTED]
---
cr.c |3 ++-
1 file
Serge E. Hallyn wrote:
Quoting Nadia Derbey ([EMAIL PROTECTED]):
Cedric Le Goater wrote:
Looks like it has worked for me (msg1 creates 1000 msg queues, sleeps
for a while and then removes the msg queues).
cool. which kernel are you using ?
C.
2.6.25-mm1 (sorry for the late answer -
Quoting Nadia Derbey ([EMAIL PROTECTED]):
Serge E. Hallyn wrote:
Quoting Nadia Derbey ([EMAIL PROTECTED]):
Cedric Le Goater wrote:
Looks like it has worked for me (msg1 creates 1000 msg queues, sleeps
for a while and then removes the msg queues).
cool. which kernel are you using ?
On Mon, 2008-06-09 at 11:23 -0500, Serge E. Hallyn wrote:
Yeah that's insurmountable - notice the stack in the process which was
fork()ed to be the restarted process topped at bfcab000, while the
checkpointed stack topped at bfdae000. You're not allowed to write
above the stack. So the
On Mon, 2008-06-09 at 11:42 -0500, Serge E. Hallyn wrote:
So, I suggest that we start using kernel coding style on this
sucker.
We're all used to it, and the original developer isn't around to
bitch
about it. :)
Yeah, agreed. That does *not* mean that I want pure style fix
patches!!
Quoting Benjamin Thery ([EMAIL PROTECTED]):
Serge,
I've cloned your cryo tree and I'm starting to play with it.
Here are a couple of trivial patches to fix some small issues
with options handling: -l (list) and -f in checkpoint mode.
Still trying to restart the 'sleep' test program.
Quoting Nadia Derbey ([EMAIL PROTECTED]):
Serge E. Hallyn wrote:
Can you check your /var/log/messages for a 'protection fault' message?
Then, if there is one for 'sleep', run gdb on sleep, take the IP in
the protection fault msg, and do 'x/10 0x8005cd0' or whatever the
address is?
No, I'm
On Mon, 2008-06-09 at 16:47 +0200, Benjamin Thery wrote:
Option -f couldn't be used in conjunction with option -p (for
checkpointing).
O_CREAT is missing in the flags passed to open().
Now, we can do:
$ cr -p MYPID -f test.cryo
(I know the coding style is not perfect (long lines,
Quoting Dave Hansen ([EMAIL PROTECTED]):
On Mon, 2008-06-09 at 11:23 -0500, Serge E. Hallyn wrote:
Yeah that's insurmountable - notice the stack in the process which was
fork()ed to be the restarted process topped at bfcab000, while the
checkpointed stack topped at bfdae000. You're
On Tue, 10 Jun 2008 01:32:58 +0200
Andrea Righi [EMAIL PROTECTED] wrote:
Provide distinct cgroup VM overcommit accounting and handling using the memory
resource controller.
Could you explain the benefits of this even when we have memrlimit controller ?
(If unsure, see 2.6.26-rc5-mm1 and
Update VM committed space statistics when a task is migrated from a cgroup to
another. To implement this feature we must keep track of the space committed by
each task (that is directly accounted in the task_struct).
Signed-off-by: Andrea Righi [EMAIL PROTECTED]
---
include/linux/sched.h |3
Per-cgroup overcommit_memory and overcommit_ratio parameters can be shown
and/or manipulated using the files memory.overcommit_memory and
memory.overcommit_ratio in the cgroup filesystem.
The file overcommit_as can be used to retrieve the current committed space
and limit of each cgroup.
Provide distinct cgroup VM overcommit accounting and handling using the memory
resource controller.
Patchset against latest Linus git tree.
This patchset allows to set different per-cgroup overcommit rules and,
according to them, it's possible to return a memory allocation failure (ENOMEM)
to
Split the different __vm_enough_memory() policies in inline functions to
easily reuse them in the memory controller overcommit handling routines.
Accounting functions vm_acct_memory() and vm_unacct_memory() are rewritten as
well, including per-cgroup committed VM accounting concept.
Documentation of the VM overcommit memory controller included in the generic
memory controller documentation: basic description and usage.
Signed-off-by: Andrea Righi [EMAIL PROTECTED]
---
Documentation/controllers/memory.txt | 29 +
1 files changed, 29
Apply the new memory controller VM prototypes to the opportune kernel routines.
Signed-off-by: Andrea Righi [EMAIL PROTECTED]
---
ipc/shm.c |6 --
kernel/fork.c |2 +-
mm/mmap.c | 10 ++
mm/mprotect.c |2 +-
mm/mremap.c |4 ++--
mm/shmem.c| 49
KAMEZAWA Hiroyuki wrote:
On Tue, 10 Jun 2008 01:32:58 +0200
Andrea Righi [EMAIL PROTECTED] wrote:
Provide distinct cgroup VM overcommit accounting and handling using the
memory
resource controller.
Could you explain the benefits of this even when we have memrlimit controller
?
(If
KOSAKI Motohiro wrote:
ChangeLog
v1 - v2
o implement can_attach() and attach() method.
o remvoe can_fork member from cgroup_subsys.
instead, copy_process() call task_cgroup_can_fork() directly.
o fixed dead lock bug.
o add
For avoiding complicated rollbacks,
I think of following ways of policy for task moving (you can add here.)
1. Before moving usage, reserve usage in the new cgroup and old cgroup.
Pros.
- rollback will be very easy.
Cons.
- A task will use twice of its own usage
21 matches
Mail list logo
