On Fri, 25 Jul 2008 17:46:45 +0100 (BST)
Hugh Dickins [EMAIL PROTECTED] wrote:
IIRC Rik expressed the same by pointing out that a cgroup at its
swap limit would then be forced to grow in mem (until it hits its
mem limit): so controlling the less precious resource would increase
pressure on
Quoting Eric W. Biederman ([EMAIL PROTECTED]):
Serge E. Hallyn [EMAIL PROTECTED] writes:
From ec5f54faf5afd16cb6cef40ebaaf3da25989d185 Mon Sep 17 00:00:00 2001
From: Serge Hallyn [EMAIL PROTECTED]
Date: Thu, 24 Jul 2008 17:52:41 -0500
Subject: [PATCH 2/6] user namespaces: move user_ns
Quoting Matt Helsley ([EMAIL PROTECTED]):
On Mon, 2008-07-28 at 14:53 -0700, Eric W. Biederman wrote:
Serge E. Hallyn [EMAIL PROTECTED] writes:
From 420d6e81ce29d7a6fe3ab7b43c1171e105f8b697 Mon Sep 17 00:00:00 2001
From: Serge Hallyn [EMAIL PROTECTED]
Date: Thu, 24 Jul 2008
Quoting Eric W. Biederman ([EMAIL PROTECTED]):
Matt Helsley [EMAIL PROTECTED] writes:
Would this require passing the vfsmount to the filesystems themselves,
or would they be within the VFS code only?
The interesting bit is the user_namespace contained in the vfsmount. We
can pass
Quoting Eric W. Biederman ([EMAIL PROTECTED]):
Serge E. Hallyn [EMAIL PROTECTED] writes:
We were talking this morning about what trivial patchset to begin
with to get a start on checkpoint and restart. We thought that
rather than start with checkpoint, maybe we should start with
Quoting Pavel Emelyanov ([EMAIL PROTECTED]):
Serge E. Hallyn wrote:
Set the pid number for a restored task. This is purely a toy, as it
only sets the pidnr in the lowest level pid namespace.
Signed-off-by: Serge Hallyn [EMAIL PROTECTED]
---
kernel/fork.c |5 +
Serge E. Hallyn [EMAIL PROTECTED] writes:
The filesystem can figure that out based on current's context, no?
With the per-sb user_ns, the default behavior is indeed very limited,
but since you want to move all the user_ns functionality into the
filesystem, the fs can tag vfsmounts based on
On Tue, 29 Jul 2008, KAMEZAWA Hiroyuki wrote:
On Fri, 25 Jul 2008 17:46:45 +0100 (BST)
Hugh Dickins [EMAIL PROTECTED] wrote:
IIRC Rik expressed the same by pointing out that a cgroup at its
swap limit would then be forced to grow in mem (until it hits its
mem limit): so controlling the
On Tue, Jul 29, 2008 at 5:31 PM, Hugh Dickins [EMAIL PROTECTED] wrote:
I don't see that I'm denying you a way to guarantee that (though I've
been thinking more of the limits than the guarantees): I'm not saying
that you cannot have a mem controller, I'm saying that you can also
have a
On Fri, 25 Jul 2008, Paul Menage wrote:
On Fri, Jul 25, 2008 at 12:46 PM, Hugh Dickins [EMAIL PROTECTED] wrote:
No, I'm trying to say something stronger than that. I'm saying,
as I've said before, that I cannot imagine why anyone would want
to control swap itself - what they want to
On Fri, 25 Jul 2008, Balbir Singh wrote:
I see what your saying. When you look at Linux right now, we control swap
independent of memory, so I am not totally opposed to setting swap, instead of
swap+mem. I might not want to swap from a particular cgroup, in which case, I
set swap to 0 and
On Wed, 30 Jul 2008 01:16:17 +0100 (BST)
Hugh Dickins [EMAIL PROTECTED] wrote:
On Tue, 29 Jul 2008, KAMEZAWA Hiroyuki wrote:
On Fri, 25 Jul 2008 17:46:45 +0100 (BST)
Hugh Dickins [EMAIL PROTECTED] wrote:
IIRC Rik expressed the same by pointing out that a cgroup at its
swap limit
I get your point. Logically this lock is unnecessary.
(And seems this patch itself is buggy..(maybe refresh miss))
BTW, I'm sorry if I misunderstand. unsigned long long (on x86-32)
can be compared safely ?
Oops... Indeed.
That discourages me, that we need a spinlock for simple comparisons
On Wed, 30 Jul 2008 10:17:19 +0900
KAMEZAWA Hiroyuki [EMAIL PROTECTED] wrote:
On Wed, 30 Jul 2008 01:16:17 +0100 (BST)
Hugh Dickins [EMAIL PROTECTED] wrote:
On Tue, 29 Jul 2008, KAMEZAWA Hiroyuki wrote:
On Fri, 25 Jul 2008 17:46:45 +0100 (BST)
Hugh Dickins [EMAIL PROTECTED] wrote:
On Wed, 30 Jul 2008 11:52:26 +0900
KAMEZAWA Hiroyuki [EMAIL PROTECTED] wrote:
mem+swap controller means a shrink to memory resource controller
(try_to_free_mem_cgroup_pages()) should drop only file caches.
(Because kick-out-to-swap will never changes the usage.)
right ? only global-lru can
In the recent mini-summit at OLS 2008 and the following days it was
agreed to tackle the checkpoint/restart (CR) by beginning with a very
simple case: save and restore a single task, with simple memory
layout, disregarding other task state such as files, signals etc.
Following these discussions
Create trivial sys_checkpoint and sys_restore system calls. They will
enable to checkpoint and restart an entire container, to and from a
checkpoint image file.
First create a template for both syscalls: they take a file descriptor
(for the image file) and flags as arguments. For sys_checkpoint
Expand the template sys_checkpoint and sys_restart to be able to dump
and restore a single task. The task's address space may consist of only
private, simple vma's - anonymous or file-mapped.
This big patch adds a mechanism to transfer data between kernel or user
space to and from the file given
On Wed, 30 Jul 2008 12:11:15 +0900
KAMEZAWA Hiroyuki [EMAIL PROTECTED] wrote:
On Wed, 30 Jul 2008 11:52:26 +0900
KAMEZAWA Hiroyuki [EMAIL PROTECTED] wrote:
mem+swap controller means a shrink to memory resource controller
(try_to_free_mem_cgroup_pages()) should drop only file caches.
On Wed, 30 Jul 2008 13:14:07 +0900, KAMEZAWA Hiroyuki [EMAIL PROTECTED] wrote:
On Wed, 30 Jul 2008 12:11:15 +0900
KAMEZAWA Hiroyuki [EMAIL PROTECTED] wrote:
On Wed, 30 Jul 2008 11:52:26 +0900
KAMEZAWA Hiroyuki [EMAIL PROTECTED] wrote:
mem+swap controller means a shrink to memory
Hi
Expand the template sys_checkpoint and sys_restart to be able to dump
and restore a single task. The task's address space may consist of only
private, simple vma's - anonymous or file-mapped.
This big patch adds a mechanism to transfer data between kernel or user
space to and from the
On Wed, 30 Jul 2008 13:58:03 +0900
Daisuke Nishimura [EMAIL PROTECTED] wrote:
On Wed, 30 Jul 2008 13:14:07 +0900, KAMEZAWA Hiroyuki [EMAIL PROTECTED]
wrote:
On Wed, 30 Jul 2008 12:11:15 +0900
KAMEZAWA Hiroyuki [EMAIL PROTECTED] wrote:
On Wed, 30 Jul 2008 11:52:26 +0900
KAMEZAWA
Sorry for many mails ;(
I think I misunderstood something...
Following is ?
A brief summary about changes in memroy controller.
- memory.limit_in_bytes works as it is now.
- new parameter: memory.limit_in_bytes_includes_swap will be added.
+ memory.limit_in_bytes_includes_swap controlls
23 matches
Mail list logo
