I realy don't want to be annoying by sending this patcheset over and over
again, i just want the issue to be solved. If anyone think this solution
is realy cappy, please comment what exectly is bad. Thank you.
Changes:
- patch was split in two patches.
- comments added. I think now it is
On Mon, Mar 12, 2007 at 10:58:10AM +0300, Dmitriy Monakhov wrote:
I realy don't want to be annoying by sending this patcheset over and over
again, i just want the issue to be solved. If anyone think this solution
is realy cappy, please comment what exectly is bad. Thank you.
If you don't get
On Mon, Mar 12, 2007 at 10:57:53AM +0300, Dmitriy Monakhov wrote:
I realy don't want to be annoying by sending this patcheset over and over
again. If anyone think this patch is realy cappy, please comment what
exectly is bad. Thank you.
Doesn't seem like a bad idea.
Changes:
- patch
Nick Piggin [EMAIL PROTECTED] writes:
On Mon, Mar 12, 2007 at 10:58:10AM +0300, Dmitriy Monakhov wrote:
I realy don't want to be annoying by sending this patcheset over and over
again, i just want the issue to be solved. If anyone think this solution
is realy cappy, please comment what
Maybe you have some ideas how we can decide on this?
We need to work out what the requirements are before we can
settle on an implementation.
Linux-VServer (and probably OpenVZ):
- shared mappings of 'shared' files (binaries
and libraries) to allow for reduced memory
footprint
On Mon, Mar 12, 2007 at 10:57:53AM +0300, Dmitriy Monakhov wrote:
+/*
+ * Performs necessary checks before doing a write
+ *
+ * Adjust number of segments and amount of bytes to write.
+ * Returns appropriate error code that caller should return or
+ * zero in case that write should be
On Mon, Mar 12, 2007 at 11:55:30AM +0300, Dmitriy Monakhov wrote:
Nick Piggin [EMAIL PROTECTED] writes:
On Mon, Mar 12, 2007 at 10:58:10AM +0300, Dmitriy Monakhov wrote:
@@ -2240,6 +2241,29 @@ ssize_t generic_file_aio_write(struct kiocb *iocb,
const struct iovec *iov,
Nick Piggin [EMAIL PROTECTED] writes:
On Mon, Mar 12, 2007 at 11:55:30AM +0300, Dmitriy Monakhov wrote:
Nick Piggin [EMAIL PROTECTED] writes:
On Mon, Mar 12, 2007 at 10:58:10AM +0300, Dmitriy Monakhov wrote:
@@ -2240,6 +2241,29 @@ ssize_t generic_file_aio_write(struct kiocb *iocb,
Allow me to annotate your nice summary. A lot of this is elaborating on
what you are saying; and I think where we disagree, the differences are
not important.
Paul Jackson wrote:
We have actors, known as threads, tasks or processes, which use things,
which are instances of such classes of
On 3/11/07, Paul Jackson [EMAIL PROTECTED] wrote:
My current understanding of Paul Menage's container patch is that it is
a useful improvement for some of the metered classes - those that could
make good use of a file system like hierarchy for their interface.
It probably doesn't benefit all
-procfs-fix-race-between-proc_readdir-and-remove_proc_entry.patch
+fix-race-between-proc_get_inode-and-remove_proc_entry.patch
Updated. Looks sane.
Why have you dropped the first patch? Resending slightly fixed version
of it.
[PATCH -mm] Fix race between proc_readdir and remove_proc_entry
On Fri, Mar 09, 2007 at 02:06:03PM -0800, Paul Jackson wrote:
if you create a 'resource container' to limit the
usage of a set of resources for the processes
belonging to this container, it would be kind of
defeating the purpose, if you'd allow the processes
to manipulate their
On Wed, Mar 07, 2007 at 03:59:19PM -0600, Serge E. Hallyn wrote:
containers patches uses just a single pointer in the task_struct, and
all tasks in the same set of containers (across all hierarchies) will
share a single container_group object, which holds the actual pointers
to container
On Sun, Mar 11, 2007 at 12:38:43PM -0700, Paul Jackson wrote:
The primary reason for the cpuset double locking, as I recall, was because
cpusets needs to access cpusets inside the memory allocator.
needs to access cpusets - can you be more specific?
Being able to safely walk cpuset-parent
On Fri, Mar 09, 2007 at 02:09:35PM -0800, Paul Menage wrote:
3. This next leads me to think that 'tasks' file in each directory doesnt
make
sense for containers. In fact it can lend itself to error situations (by
administrator/script mistake) when some tasks of a container are in
Quoting Srivatsa Vaddagiri ([EMAIL PROTECTED]):
On Fri, Mar 09, 2007 at 02:09:35PM -0800, Paul Menage wrote:
3. This next leads me to think that 'tasks' file in each directory doesnt
make
sense for containers. In fact it can lend itself to error situations
(by
Eric W. Biederman wrote:
Pavel Emelianov [EMAIL PROTECTED] writes:
Adds needed pointers to mm_struct and page struct,
places hooks to core code for mm_struct initialization
and hooks in container_init_early() to preinitialize
RSS accounting subsystem.
An extra pointer in struct page is
On Mon, 2007-03-12 at 19:16 +0300, Kirill Korotaev wrote:
now VE2 maps the same page. You can't determine whether this page is mapped
to this container or another one w/o page-container pointer.
Hi Kirill,
I thought we can always get from the page to the VMA. rmap provides
this to us via
On Mon, 2007-03-12 at 19:23 +0300, Kirill Korotaev wrote:
For these you essentially need per-container page-_mapcount counter,
otherwise you can't detect whether rss group still has the page in question
being mapped
in its processes' address spaces or not.
What do you mean by this? You
On Sat, 2007-03-10 at 02:36 +0100, Herbert Poetzl wrote:
you mount a filesystem inside a namespace, so that
only the guest will see it (in theory) now you somehow
show that in the namespace copy too (on the host system)
and if some task decides to go camping there (cd into
that) it might keep
Dave Hansen wrote:
On Mon, 2007-03-12 at 19:16 +0300, Kirill Korotaev wrote:
now VE2 maps the same page. You can't determine whether this page is mapped
to this container or another one w/o page-container pointer.
Hi Kirill,
I thought we can always get from the page to the VMA. rmap
On 3/12/07, Dave Hansen [EMAIL PROTECTED] wrote:
On Mon, 2007-03-12 at 19:16 +0300, Kirill Korotaev wrote:
now VE2 maps the same page. You can't determine whether this page is mapped
to this container or another one w/o page-container pointer.
Hi Kirill,
I thought we can always get from
On Mon, 2007-03-12 at 20:19 +0300, Pavel Emelianov wrote:
Dave Hansen wrote:
On Mon, 2007-03-12 at 19:16 +0300, Kirill Korotaev wrote:
now VE2 maps the same page. You can't determine whether this page is mapped
to this container or another one w/o page-container pointer.
Hi Kirill,
Quoting Srivatsa Vaddagiri ([EMAIL PROTECTED]):
On Mon, Mar 12, 2007 at 10:56:43AM -0500, Serge E. Hallyn wrote:
What's wrong with that?
I had been asking around on what is the fundamental unit of res mgmt
for vservers and the answer I got (from Herbert) was all tasks that are
in the same
How about we drill down on these a bit more.
On Mon, 2007-03-12 at 02:00 +0100, Herbert Poetzl wrote:
- shared mappings of 'shared' files (binaries
and libraries) to allow for reduced memory
footprint when N identical guests are running
So, it sounds like this can be phrased as a
Changes against v6
- remove duplicated code from xfs,ntfs
- export generic_segment_checks, because it used by xfs,nfs now.
- change arguments initialization pocily according to Nick's comments.
Tested with: ltp readv/writev tests
Signed-off-by: Monakhov Dmitriy [EMAIL PROTECTED]
---
Changes against v6:
- Handle direct_io failure inside generic_file_direct_write() as it was
recommend by Andrew (during discussion v1), and by Nick (during
discussion v6).
- change comments, make it more clear.
- one more time check what __generic_file_aio_write_nolock() always called
On Mon, Mar 12, 2007 at 03:00:25AM -0700, Paul Menage wrote:
On 3/11/07, Paul Jackson [EMAIL PROTECTED] wrote:
My current understanding of Paul Menage's container patch is that it is
a useful improvement for some of the metered classes - those that could
make good use of a file system
On Tue, Mar 13, 2007 at 07:27:06AM +0530, Balbir Singh wrote:
I am not sure what went wrong. Could you please check your mail
client, cause it seemed to even change email address to smtp.osdl.org
which bounced back when I wrote to you earlier.
I have a problem doing a group-reply in mutt to
Eric W. Biederman [EMAIL PROTECTED] wrote:
| [EMAIL PROTECTED] writes:
|
| From: Cedric Le Goater [EMAIL PROTECTED]
| Subject: [RFC][PATCH 6/6]: Enable unsharing pid namespace.
|
| Enable unsharing of pid namespace - i.e allow creating and using
| a new pid namespace and attaching multiple
From: Sukadev Bhattiprolu [EMAIL PROTECTED]
Subject: [PATCH 4/5] Remove the likely(pid) check in copy_process
Now that we pass in a struct pid parameter to copy_process()
and even the swapper (pid_t == 0) has a valid struct pid,
we no longer need this check.
Changelog:
Per Eric
From: Sukadev Bhattiprolu [EMAIL PROTECTED]
Subject: [PATCH] Kill unused sesssion and group values in rocket driver
The process_session() and process_group() values are not really
used by the driver.
Signed-off-by: Sukadev Bhattiprolu [EMAIL PROTECTED]
Cc: Cedric Le Goater [EMAIL PROTECTED]
Cc:
From: Sukadev Bhattiprolu [EMAIL PROTECTED]
Subject: [PATCH 1/2] Fix some coding-style errors in autofs
Fix coding style errors (extra spaces, long lines) in autofs
and autofs4 files being modified for container/pidspace issues.
Signed-off-by: Sukadev Bhattiprolu [EMAIL PROTECTED]
Cc: Cedric Le
From: Sukadev Bhattiprolu [EMAIL PROTECTED]
Subject: [PATCH 2/2] Replace pid_t in autofs with struct pid reference.
Make autofs container-friendly by caching struct pid reference rather
than pid_t and using pid_nr() to retreive a task's pid_t.
ChangeLog:
- Fix Eric Biederman's comments
On 3/12/07, Herbert Poetzl [EMAIL PROTECTED] wrote:
why? you simply enter that specific space and
use the existing mechanisms (netlink, proc, whatever)
to retrieve the information with _existing_ tools,
That's assuming that you're using network namespace virtualization,
with each group of
35 matches
Mail list logo
