Paul Menage wrote:
[snip]
Some possible subsystems that I'm thinking of include:
- splitting the memory and cpu isolation parts of cpusets into two
separate subsystems (still backwards-compatible)
I see memory isolation using cpusets as very topology dependent
and I am not sure if the model
On 7/9/07, Balbir Singh [EMAIL PROTECTED] wrote:
- splitting the memory and cpu isolation parts of cpusets into two
separate subsystems (still backwards-compatible)
I see memory isolation using cpusets as very topology dependent
and I am not sure if the model would work for memory
Cedric Le Goater wrote:
Pavel Emelianov wrote:
The most importaint change is moving exit_task_namespaces()
inside exit_notify() to makes it possible to notify the
exiting task's parent. However this should be done before
release_task() to address the issue pointed by Sukadev with
NFS kernel
[EMAIL PROTECTED] wrote:
Pavel Emelianov [EMAIL PROTECTED] wrote:
| When searching the task by numerical id on may need to find
| it using global pid (as it is done now in kernel) or by its
| virtual id, e.g. when sending a signal to a task from one
| namespace the sender will specify the
Cedric Le Goater wrote:
Pavel Emelianov wrote:
The set of functions process_session, task_session, process_group
and task_pgrp is confusing, as the names can be mixed with each other
when looking at the code for a long time.
The proposals are to
* equip the functions that return the integer
[EMAIL PROTECTED] wrote:
Pavel Emelianov [EMAIL PROTECTED] wrote:
| When showing pid to user or getting the pid numerical id for in-kernel
| use the value of this id may differ depending on the namespace.
|
| This set of helpers is used to get the global pid nr, the virtual (i.e.
| seen by
[EMAIL PROTECTED] wrote:
Pavel Emelianov [EMAIL PROTECTED] wrote:
| When user send signal from (say) init namespace to any task in a sub
| namespace the siginfo struct must not carry the sender's pid value, as
| this value may refer to some task in the destination namespace and thus
| may
Paul Menage wrote:
On 7/9/07, Balbir Singh [EMAIL PROTECTED] wrote:
- splitting the memory and cpu isolation parts of cpusets into two
separate subsystems (still backwards-compatible)
I see memory isolation using cpusets as very topology dependent
and I am not sure if the model would work
[EMAIL PROTECTED] wrote:
Cedric Le Goater [EMAIL PROTECTED] wrote:
| Pavel Emelianov wrote:
| struct pid_namespace will have the kmem_cache to allocate
| the pids from, the parent, as they are hierarchical, and
| the level of nesting value.
|
| struct pid will have a variable length
Badari Pulavarty wrote:
On Mon, 2007-07-09 at 22:06 +0200, Cedric Le Goater wrote:
Badari Pulavarty wrote:
On Fri, 2007-07-06 at 12:01 +0400, Pavel Emelianov wrote:
This is submition for inclusion of hierarchical, not kconfig
configurable, zero overheaded ;) pid namespaces.
Not able to boot
Kirill, Serge, et al,
Is it fair to say then that Paul Menage's containers are primarily
for the purposes of managing resources, while namespaces are for the
purposes of managing identifiers?
We've got some resources, like cpu cycles, memory bytes, network
bandwidth, that we want to allocate and
Balbir wrote:
Aaah.. I see, that makes sense from a cpusets/containers perspective.
Agreed.
--
I won't rest till it's the best ...
Programmer, Linux Scalability
Paul Jackson [EMAIL PROTECTED] 1.925.600.0401
On Tue, 10 Jul 2007 10:40:13 +0400 Pavel Emelianov [EMAIL PROTECTED] wrote:
I think we are all ok with it. right ?
Right. That's already the 3rd time I send it to Andrew...
I'm basically ignoring all the containers/resource-control stuff, waiting
for it to appear to have settled down. It's
On 7/10/07, Paul Jackson [EMAIL PROTECTED] wrote:
Kirill, Serge, et al,
Is it fair to say then that Paul Menage's containers are primarily
for the purposes of managing resources, while namespaces are for the
purposes of managing identifiers?
Sort of - but one thing that we're trying to figure
Paul M wrote:
Sort of - but ...
Thanks for your reply.
I guess I'll just have to wander off, still a tad confused.
I suspect my instincts are running in a contrary direction to those,
including yourself, doing the work here. My preference is to pick
a subset of the task before me that I can
On 7/10/07, YAMAMOTO Takashi [EMAIL PROTECTED] wrote:
hi,
diff -puN mm/memory.c~mem-control-accounting mm/memory.c
--- linux-2.6.22-rc6/mm/memory.c~mem-control-accounting 2007-07-05
13:45:18.0 -0700
+++ linux-2.6.22-rc6-balbir/mm/memory.c 2007-07-05 13:45:18.0
[EMAIL PROTECTED] wrote:
Pavel Emelianov [EMAIL PROTECTED] wrote:
| This is submition for inclusion of hierarchical, not kconfig
| configurable, zero overheaded ;) pid namespaces.
|
| The overall idea is the following:
|
| The namespace are organized as a tree - once a task is cloned
|
On Tue, Jul 10, 2007 at 01:31:52AM -0700, Andrew Morton wrote:
cpuset-zero-malloc-revert-the-old-cpuset-fix.patch
containersv10-basic-container-framework.patch
containersv10-basic-container-framework-fix.patch
containersv10-basic-container-framework-fix-2.patch
Cedric Le Goater wrote:
Badari Pulavarty wrote:
On Fri, 2007-07-06 at 12:01 +0400, Pavel Emelianov wrote:
This is submition for inclusion of hierarchical, not kconfig
configurable, zero overheaded ;) pid namespaces.
Not able to boot my ppc64 machine with the patchset :(
I can't boot either
| +
| struct pid
| {
| atomic_t count;
| @@ -40,6 +40,8 @@ enum pid_type
| /* lists of tasks that use this pid */
| struct hlist_head tasks[PIDTYPE_MAX];
| struct rcu_head rcu;
| +int level;
| +struct pid_number numbers[1];
Pavel Emelianov wrote:
Cedric Le Goater wrote:
Badari Pulavarty wrote:
On Fri, 2007-07-06 at 12:01 +0400, Pavel Emelianov wrote:
This is submition for inclusion of hierarchical, not kconfig
configurable, zero overheaded ;) pid namespaces.
Not able to boot my ppc64 machine with the patchset
Daniel Lezcano wrote:
Pavel Emelianov wrote:
Cedric Le Goater wrote:
Badari Pulavarty wrote:
On Fri, 2007-07-06 at 12:01 +0400, Pavel Emelianov wrote:
This is submition for inclusion of hierarchical, not kconfig
configurable, zero overheaded ;) pid namespaces.
Not able to boot my ppc64
Not able to boot my ppc64 machine with the patchset :(
Thanks,
Badari
That's the hunk lost during the split:
--- ./fs/proc/root.c.procfix2007-07-10 13:52:08.0 +0400
+++ ./fs/proc/root.c2007-07-10 15:23:20.0 +0400
@@ -111,7 +111,7 @@ void __init proc_root_init(void)
[EMAIL PROTECTED] wrote:
Pavel Emelianov [EMAIL PROTECTED] wrote:
| This is submition for inclusion of hierarchical, not kconfig
| configurable, zero overheaded ;) pid namespaces.
|
| The overall idea is the following:
|
| The namespace are organized as a tree - once a task is cloned
|
The set of functions process_session, task_session, process_group
and task_pgrp is confusing, as the names can be mixed with each other
when looking at the code for a long time.
The proposals are to
* equip the functions that return the integer with _nr suffix to
represent that fact,
* and to
Add kmem_cache to pid_namespace to allocate pids from.
Since booth implementations expand the struct pid to carry
more numerical values each namespace should have separate
cache to store pids of different sizes.
Each kmem cache is names pid_NR, where NR is the number
of numerical ids on the pid.
These patches were acked by all the people who is interested in
having pid namespace in the kernel and proposed for inclusion.
Made against 2.6.22-rc6-mm1 and checked on i386 and x86_64 nodes.
[PATCH 1/3] - Api rename.
Acked by Cedric Le Goater.
[PATCH 2/3] - Small improvement of
On Mon, 09 Jul 2007 21:44:31 -0700 Balbir Singh wrote:
Peter Zijlstra wrote:
On Sun, 2028-02-27 at 02:39 -0500, Balbir Singh wrote:
I am not a CLUI expert, but rounding off bytes will something that
the administrators will probably complain about. Since we manage
the controller memory
YAMAMOTO Takashi wrote:
Add the meta_page to the per container LRU. The reclaim algorithm has been
modified to make the isolate_lru_pages() as a pluggable component. The
scan_control data structure now accepts the container on behalf of which
reclaims are carried out. try_to_free_pages() has
YAMAMOTO Takashi wrote:
On 7/10/07, YAMAMOTO Takashi [EMAIL PROTECTED] wrote:
hi,
diff -puN mm/memory.c~mem-control-accounting mm/memory.c
--- linux-2.6.22-rc6/mm/memory.c~mem-control-accounting 2007-07-05
13:45:18.0 -0700
+++ linux-2.6.22-rc6-balbir/mm/memory.c
Randy Dunlap wrote:
Hmm.. yes.. a library routine would be nice!
you mean something like lib/cmdline.c::memparse() ?
Excellent, one of the reasons to love Linux (there's already
code) :-)
--
Warm Regards,
Balbir Singh
Linux Technology Center
IBM, ISTL
Quoting Paul Jackson ([EMAIL PROTECTED]):
Kirill, Serge, et al,
Is it fair to say then that Paul Menage's containers are primarily
for the purposes of managing resources, while namespaces are for the
purposes of managing identifiers?
We've got some resources, like cpu cycles, memory
On 7/10/07, Srivatsa Vaddagiri [EMAIL PROTECTED] wrote:
Container stuff. Hold, I guess. I was expecting updates from Paul.
Paul,
Are you working on a new version? I thought it was mostly ready
for mainline.
There are definitely some big changes that I want to make internally
to
On Tue, 10 Jul 2007 11:34:38 -0700
Paul Menage [EMAIL PROTECTED] wrote:
Andrew, how about we merge enough of the container framework to
support CFS? Bits we could leave out for now include container_clone()
support and the nsproxy subsystem, fork/exit callback hooks, and
possibly leave
On 7/10/07, Andrew Morton [EMAIL PROTECTED] wrote:
Andrew, how about we merge enough of the container framework to
support CFS? Bits we could leave out for now include container_clone()
support and the nsproxy subsystem, fork/exit callback hooks, and
possibly leave cpusets alone for now
On Tue, 2007-07-10 at 15:30 +0400, Pavel Emelianov wrote:
Cedric Le Goater wrote:
Badari Pulavarty wrote:
On Fri, 2007-07-06 at 12:01 +0400, Pavel Emelianov wrote:
This is submition for inclusion of hierarchical, not kconfig
configurable, zero overheaded ;) pid namespaces.
Not able to
Quoting Herbert Poetzl ([EMAIL PROTECTED]):
On Mon, Jul 02, 2007 at 11:55:04AM -0500, Serge E. Hallyn wrote:
We are trying to create a roadmap for the next year of
'container' development, to be reported to the upcoming kernel
summit. Containers here is a bit of an ambiguous term, so we
On Tue, 2007-07-10 at 17:06 +0400, Pavel Emelianov wrote:
Not able to boot my ppc64 machine with the patchset :(
Thanks,
Badari
That's the hunk lost during the split:
--- ./fs/proc/root.c.procfix 2007-07-10 13:52:08.0 +0400
+++ ./fs/proc/root.c 2007-07-10
Quoting Serge E. Hallyn ([EMAIL PROTECTED]):
Quoting Paul Jackson ([EMAIL PROTECTED]):
Kirill, Serge, et al,
Is it fair to say then that Paul Menage's containers are primarily
for the purposes of managing resources, while namespaces are for the
purposes of managing identifiers?
(If you missed earlier parts of this thread, you can catch earlier parts of
this thread starting at
https://lists.linux-foundation.org/pipermail/containers/2007-July/005860.html)
Thanks for all the recent feedback. I particularly added a lot from Paul
Menage and Cedric.
We are trying to create
On Tue, 10 Jul 2007 16:39:43 -0500
Serge E. Hallyn [EMAIL PROTECTED] wrote:
In the list of stakeholders, I try to guess based on past comments and
contributions what *general* area they are most likely to contribute in.
I may try to narrow those down later, but am just trying to get something
On Tue, 10 Jul 2007 16:39:43 -0500
Serge E. Hallyn [EMAIL PROTECTED] wrote:
We are trying to create a roadmap for the next year of
'container' development, to be reported to the upcoming kernel
summit. Containers here is a bit of an ambiguous term, so we are
taking it to mean all of:
On Tue, Jul 10, 2007 at 11:53:19AM -0700, Andrew Morton wrote:
On Tue, 10 Jul 2007 11:34:38 -0700
Paul Menage [EMAIL PROTECTED] wrote:
Andrew, how about we merge enough of the container framework to
support CFS? Bits we could leave out for now include container_clone()
support and the
On Wed, 11 Jul 2007 10:25:16 +0530 Srivatsa Vaddagiri [EMAIL PROTECTED] wrote:
On Tue, Jul 10, 2007 at 11:53:19AM -0700, Andrew Morton wrote:
On Tue, 10 Jul 2007 11:34:38 -0700
Paul Menage [EMAIL PROTECTED] wrote:
Andrew, how about we merge enough of the container framework to
On Tue, Jul 10, 2007 at 10:29:42PM -0700, Andrew Morton wrote:
I'm inclined to take the cautious route here - I don't think people will be
dying for the CFS thingy (which I didn't even know about?) in .23, and it's
rather a lot of infrastructure to add for a CPU scheduler configurator
gadget
45 matches
Mail list logo
