Eric W. Biederman wrote:
[EMAIL PROTECTED] writes:
[PATCH 05/05]
This patch uses the value written into the next_syscall_data proc file
as a target file descriptor for the next file to be opened.
This makes it easy to restart a process with the same fds as the ones it was
using during the
This is an initial design for a transactional task attachment
framework for cgroups. There are probably some potential simplications
that I've missed, particularly in the area of locking. Comments
appreciated.
The Problem
===
Currently cgroups task movements are done in three phases
1)
Pavel Machek wrote:
On Tue 2008-07-08 16:47:21, Serge E. Hallyn wrote:
Quoting Pavel Machek ([EMAIL PROTECTED]):
Hi!
An alternative to this solution consists in defining a new field in the
task structure (let's call it next_syscall_data) that, if set, would
change
the behavior of next
On Wed, Jul 9, 2008 at 11:54 PM, Nadia Derbey [EMAIL PROTECTED] wrote:
Don't you think it's simpler to specify the target fd, and then open the
file.
Maybe. But:
- this can already be done without extra kernel support, via open()
followed by dup2()
- if you were going to add it to the
Pavel Machek wrote:
Hi!
An alternative to this solution consists in defining a new field in the
task structure (let's call it next_syscall_data) that, if set, would change
the behavior of next syscall to be called. The sys_fork_with_id() previously
cited can be replaced by
1) set
Serge E. Hallyn wrote:
Quoting Pavel Machek ([EMAIL PROTECTED]):
An alternative to this solution consists in defining a new field in the
task structure (let's call it next_syscall_data) that, if set, would
change
the behavior of next syscall to be called. The sys_fork_with_id()
previously
Eric W. Biederman wrote:
[EMAIL PROTECTED] writes:
[PATCH 03/05]
This patch uses the value written into the next_syscall_data proc file
as a target upid nr for the next process to be created.
The following syscalls have a new behavior if next_syscall_data is set:
. fork()
. vfork()
. clone()
On Thu, Jul 10, 2008 at 12:58 AM, Nadia Derbey [EMAIL PROTECTED] wrote:
Actually, what I've started working on these days is replace the proc
interface by a syscall to set the next_syscall_data field: I think this
might help us avoid defining a precise list of the new syscalls we need?
Isn't
On Thu 2008-07-10 09:42:03, Nadia Derbey wrote:
Pavel Machek wrote:
Hi!
An alternative to this solution consists in defining a new field in the
task structure (let's call it next_syscall_data) that, if set, would
change
the behavior of next syscall to be called. The sys_fork_with_id()
On Thu, Jul 10, 2008 at 2:14 AM, Nadia Derbey [EMAIL PROTECTED] wrote:
But I think that both ways of doing are not exactly the same in case of
failure:
open + dup2 will close newfd if it is already busy.
while
next-syscall_data + open will fail if the target fd is already busy. And
that's
Paul Menage wrote:
On Thu, Jul 10, 2008 at 12:58 AM, Nadia Derbey [EMAIL PROTECTED] wrote:
Actually, what I've started working on these days is replace the proc
interface by a syscall to set the next_syscall_data field: I think this
might help us avoid defining a precise list of the new
Nadia Derbey [EMAIL PROTECTED] writes:
If I correctly understood what you're saying, it means set min = max =
target_pid using /proc/sys, i.e. for the whole system: don't you think this
might be dangerous: allocating pids will fail for any other running process
during the entire period of
Pavel Emelyanov wrote:
Please pull from
git://git.openvz.org/pub/ubuntu-hardy-openvz openvz
to receive fixes back-ported from stable 028stab053 kernel branch.
The fixes summary is:
* CPT crashes when some restoring to already running Container
* OOPS when CPT failed to dump
Quoting KAMEZAWA Hiroyuki ([EMAIL PROTECTED]):
On Wed, 09 Jul 2008 14:58:43 -0700
Matt Helsley [EMAIL PROTECTED] wrote:
On Tue, 2008-07-08 at 13:07 -0700, Paul Menage wrote:
On Tue, Jul 8, 2008 at 1:06 PM, Paul Menage [EMAIL PROTECTED] wrote:
On Tue, Jul 8, 2008 at 12:39 PM, Matt
On Thu, 2008-07-10 at 02:10 +0400, Alexey Dobriyan wrote:
How, for example, dump all VMAs correctly?
[prepares counter-example]
Are there some particular pitfalls that you'd like to share? I'd love
to hear some of the issues the you've run into with Virtuozzo as its
implementation was created.
On Wed, 2008-07-09 at 18:58 -0700, Eric W. Biederman wrote:
In the worst case today we can restore a checkpoint by replaying all of
the user space actions that took us to get there. That is a tedious
and slow approach.
Yes, tedious and slow, *and* minimally invasive in the kernel. Once we
Quoting Dave Hansen ([EMAIL PROTECTED]):
On Wed, 2008-07-09 at 18:58 -0700, Eric W. Biederman wrote:
In the worst case today we can restore a checkpoint by replaying all of
the user space actions that took us to get there. That is a tedious
and slow approach.
Yes, tedious and slow,
On Thu, 2008-07-10 at 10:54 +0200, Pavel Machek wrote:
If you don't see a backward compatibility problem here, perhaps you
should not be hacking kernel...? The way ids are assigned is certainly
part of syscall semantics (applications rely on), at least for open.
We also used to have a pretty
On Thu 2008-07-10 10:53:35, Dave Hansen wrote:
On Thu, 2008-07-10 at 10:54 +0200, Pavel Machek wrote:
If you don't see a backward compatibility problem here, perhaps you
should not be hacking kernel...? The way ids are assigned is certainly
part of syscall semantics (applications rely
Serge E. Hallyn [EMAIL PROTECTED] writes:
So, the checkpoint-as-a-corefile idea sounds good to me, but it
definitely leaves a lot of questions about exactly how we'll need to do
the restore.
Talking with Dave over irc, I kind of liked the idea of creating a new
fs/binfmt_cr.c that executes
On Thu, 2008-07-10 at 20:45 +0200, Pavel Machek wrote:
On Thu 2008-07-10 10:53:35, Dave Hansen wrote:
On Thu, 2008-07-10 at 10:54 +0200, Pavel Machek wrote:
If you don't see a backward compatibility problem here, perhaps you
should not be hacking kernel...? The way ids are assigned is
On Thu, 2008-07-10 at 11:55 -0700, Eric W. Biederman wrote:
If we do checkpoint-as-a-coredump, then we need userspace to coordinate
a kernel-generated coredump with a user-generated (?) swapfile snapshot.
But I guess we figure that out later.
Well it is a matter of which VMAs you dump.
Quoting Dave Hansen ([EMAIL PROTECTED]):
On Thu, 2008-07-10 at 20:45 +0200, Pavel Machek wrote:
On Thu 2008-07-10 10:53:35, Dave Hansen wrote:
On Thu, 2008-07-10 at 10:54 +0200, Pavel Machek wrote:
If you don't see a backward compatibility problem here, perhaps you
should not be
Dave Hansen [EMAIL PROTECTED] writes:
On Thu, 2008-07-10 at 11:55 -0700, Eric W. Biederman wrote:
If we do checkpoint-as-a-coredump, then we need userspace to coordinate
a kernel-generated coredump with a user-generated (?) swapfile snapshot.
But I guess we figure that out later.
Well
On Thu, 2008-07-10 at 12:21 -0700, Eric W. Biederman wrote:
Are we talking about the VMA itself, or the memory backing the VMA?
The memory backing the VMA. We need to store the page protections
that the memory was mapped with as well now that you point it out. A
VMA is not user space
From: Cedric Le Goater [EMAIL PROTECTED]
This patch add a helper routine get_sb_single_ns() which allocates
a single super_block per instance of namespace. The data parameter
is used to differentiate the namespaces.
This is used in subsystems with an internal fs like mqueue.
TODO:
-
From: Cedric Le Goater [EMAIL PROTECTED]
Largely inspired from ipc/ipc_sysctl.c. This patch isolates the mqueue
sysctl stuff in its own file.
Signed-off-by: Cedric Le Goater [EMAIL PROTECTED]
---
linux-2.6.git-dave/include/linux/mq_namespace.h | 10 ++
linux-2.6.git-dave/init/Kconfig
From: Cedric Le Goater [EMAIL PROTECTED]
This patch includes the mqueue namespace in the nsproxy object. It
also adds the support of unshare() and clone() with a new clone flag.
It's totally harmless for the moment because the current code still
uses the default mqueue namespace object
From: Cedric Le Goater [EMAIL PROTECTED]
Move forward and start using the mqueue namespace.
The single super block mount of the file system is modified to allow
one mount per namespace. This is achieved by storing the namespace
in the super_block s_fs_info attribute.
Changes since v5 Feb
From: Cedric Le Goater [EMAIL PROTECTED]
This patch adds a struct mq_namespace holding the common attributes
of the mqueue namespace.
The current code is modified to use the default mqueue namespace
object 'init_mq_ns' and to prepare the ground for futur dynamic
objects.
A new option
Dave Hansen [EMAIL PROTECTED]
From: Cedric Le Goater [EMAIL PROTECTED]
This patch includes the mqueue namespace in the nsproxy object. It
also adds the support of unshare() and clone() with a new clone flag.
^^^
It's totally harmless
On Wed, 9 Jul 2008 15:00:34 +0900 (JST)
[EMAIL PROTECTED] (YAMAMOTO Takashi) wrote:
hi,
the following patch is a simple implementation of
dirty balancing for cgroups. any comments?
it depends on the following fix:
http://lkml.org/lkml/2008/7/8/428
A few comments ;)
- This
Thank you for your effort.
On Wed, 9 Jul 2008 23:46:33 -0700
Paul Menage [EMAIL PROTECTED] wrote:
3) memory
Curently the memory cgroup only uses the mm-owner's cgroup at charge
time, and keeps a reference to the cgroup on the page. However,
patches have been proposed that would move all
On Thu, Jul 10, 2008 at 12:47:32PM -0700, Dave Hansen wrote:
On Thu, 2008-07-10 at 12:21 -0700, Eric W. Biederman wrote:
Are we talking about the VMA itself, or the memory backing the VMA?
The memory backing the VMA. We need to store the page protections
that the memory was mapped with
Paul Menage wrote:
This is an initial design for a transactional task attachment
framework for cgroups. There are probably some potential simplications
that I've missed, particularly in the area of locking. Comments
appreciated.
Though not so elegant, it sounds workable in practise.
On Thu, Jul 10, 2008 at 7:14 PM, Li Zefan [EMAIL PROTECTED] wrote:
Support for CGROUP_ATTACH_PROCESS adds complexity and some subsystems
may have to aware of this and write code to support it, but fortunately
it seems only numtasks needs to deal with this. Or we can implement
this new task
hi,
On Wed, 9 Jul 2008 15:00:34 +0900 (JST)
[EMAIL PROTECTED] (YAMAMOTO Takashi) wrote:
hi,
the following patch is a simple implementation of
dirty balancing for cgroups. any comments?
it depends on the following fix:
http://lkml.org/lkml/2008/7/8/428
A few
On Fri, 11 Jul 2008 13:06:57 +0900 (JST)
[EMAIL PROTECTED] (YAMAMOTO Takashi) wrote:
hi,
On Wed, 9 Jul 2008 15:00:34 +0900 (JST)
[EMAIL PROTECTED] (YAMAMOTO Takashi) wrote:
hi,
the following patch is a simple implementation of
dirty balancing for cgroups. any comments?
38 matches
Mail list logo
