On Wed, Jun 19, 2013 at 02:59:17PM -0400, Theodore Ts'o wrote:
On Wed, Jun 19, 2013 at 10:06:35AM -0700, Andrew Morton wrote:
Merge the ext4 change early, please. The core shrinker changes aren't
100% certain at this time - first they need to stop oopsing ;)
Ack, sounds like a plan.
On Tue, Jun 18, 2013 at 10:19:31AM +0200, Michal Hocko wrote:
> On Tue 18-06-13 02:30:05, Glauber Costa wrote:
> > On Mon, Jun 17, 2013 at 02:35:08PM -0700, Andrew Morton wrote:
> [...]
> > > The trace says shrink_slab_node->super_cache_scan->prune_icach
On Tue, Jun 18, 2013 at 12:46:23PM +1000, Dave Chinner wrote:
> On Tue, Jun 18, 2013 at 02:30:05AM +0400, Glauber Costa wrote:
> > On Mon, Jun 17, 2013 at 02:35:08PM -0700, Andrew Morton wrote:
> > > On Mon, 17 Jun 2013 19:14:12 +0400 Glauber Costa
> > > wrote:
On Tue, Jun 18, 2013 at 02:30:05AM +0400, Glauber Costa wrote:
> On Mon, Jun 17, 2013 at 02:35:08PM -0700, Andrew Morton wrote:
> > On Mon, 17 Jun 2013 19:14:12 +0400 Glauber Costa wrote:
> >
> > > > I managed to trigger:
> > > > [ 1015
On Tue, Jun 18, 2013 at 02:30:05AM +0400, Glauber Costa wrote:
On Mon, Jun 17, 2013 at 02:35:08PM -0700, Andrew Morton wrote:
On Mon, 17 Jun 2013 19:14:12 +0400 Glauber Costa glom...@gmail.com wrote:
I managed to trigger:
[ 1015.776029] kernel BUG at mm/list_lru.c:92
On Tue, Jun 18, 2013 at 12:46:23PM +1000, Dave Chinner wrote:
On Tue, Jun 18, 2013 at 02:30:05AM +0400, Glauber Costa wrote:
On Mon, Jun 17, 2013 at 02:35:08PM -0700, Andrew Morton wrote:
On Mon, 17 Jun 2013 19:14:12 +0400 Glauber Costa glom...@gmail.com
wrote:
I managed
On Tue, Jun 18, 2013 at 10:19:31AM +0200, Michal Hocko wrote:
On Tue 18-06-13 02:30:05, Glauber Costa wrote:
On Mon, Jun 17, 2013 at 02:35:08PM -0700, Andrew Morton wrote:
[...]
The trace says shrink_slab_node-super_cache_scan-prune_icache_sb. So
it's inodes?
Assuming
On Mon, Jun 17, 2013 at 02:35:08PM -0700, Andrew Morton wrote:
> On Mon, 17 Jun 2013 19:14:12 +0400 Glauber Costa wrote:
>
> > > I managed to trigger:
> > > [ 1015.776029] kernel BUG at mm/list_lru.c:92!
> > > [ 1015.776029] invalid opcode: [#1] SMP
>
On Mon, Jun 17, 2013 at 05:33:02PM +0200, Michal Hocko wrote:
> On Mon 17-06-13 19:14:12, Glauber Costa wrote:
> > On Mon, Jun 17, 2013 at 04:18:22PM +0200, Michal Hocko wrote:
> > > Hi,
> >
> > Hi,
> >
> > > I managed to trigger:
> &
On Mon, Jun 17, 2013 at 04:18:22PM +0200, Michal Hocko wrote:
> Hi,
Hi,
> I managed to trigger:
> [ 1015.776029] kernel BUG at mm/list_lru.c:92!
> [ 1015.776029] invalid opcode: [#1] SMP
> with Linux next (next-20130607) with https://lkml.org/lkml/2013/6/17/203
> on top.
>
> This is
On Mon, Jun 17, 2013 at 04:18:22PM +0200, Michal Hocko wrote:
Hi,
Hi,
I managed to trigger:
[ 1015.776029] kernel BUG at mm/list_lru.c:92!
[ 1015.776029] invalid opcode: [#1] SMP
with Linux next (next-20130607) with https://lkml.org/lkml/2013/6/17/203
on top.
This is obviously
On Mon, Jun 17, 2013 at 05:33:02PM +0200, Michal Hocko wrote:
On Mon 17-06-13 19:14:12, Glauber Costa wrote:
On Mon, Jun 17, 2013 at 04:18:22PM +0200, Michal Hocko wrote:
Hi,
Hi,
I managed to trigger:
[ 1015.776029] kernel BUG at mm/list_lru.c:92!
[ 1015.776029] invalid
On Mon, Jun 17, 2013 at 02:35:08PM -0700, Andrew Morton wrote:
On Mon, 17 Jun 2013 19:14:12 +0400 Glauber Costa glom...@gmail.com wrote:
I managed to trigger:
[ 1015.776029] kernel BUG at mm/list_lru.c:92!
[ 1015.776029] invalid opcode: [#1] SMP
with Linux next (next-20130607
On Fri, Jun 14, 2013 at 02:55:39PM +0200, Michal Hocko wrote:
> On Wed 12-06-13 21:04:58, Tejun Heo wrote:
> [...]
> > +/**
> > + * cgroup_destroy_locked - the first stage of cgroup destruction
> > + * @cgrp: cgroup to be destroyed
> > + *
> > + * css's make use of percpu refcnts whose killing
On Fri, Jun 14, 2013 at 09:17:40AM +0800, Li Zefan wrote:
> >> static void memcg_kmem_mark_dead(struct mem_cgroup *memcg)
> >> {
> >> + /*
> >> + * We need to call css_get() first, because memcg_uncharge_kmem()
> >> + * will call css_put() if it sees the memcg is dead.
> >> + */
> >> +
On Fri, Jun 14, 2013 at 09:17:40AM +0800, Li Zefan wrote:
static void memcg_kmem_mark_dead(struct mem_cgroup *memcg)
{
+ /*
+ * We need to call css_get() first, because memcg_uncharge_kmem()
+ * will call css_put() if it sees the memcg is dead.
+ */
+ smb_wmb();
if
On Fri, Jun 14, 2013 at 02:55:39PM +0200, Michal Hocko wrote:
On Wed 12-06-13 21:04:58, Tejun Heo wrote:
[...]
+/**
+ * cgroup_destroy_locked - the first stage of cgroup destruction
+ * @cgrp: cgroup to be destroyed
+ *
+ * css's make use of percpu refcnts whose killing latency
On 06/06/2013 05:49 AM, Tejun Heo wrote:
> I generally agree with the approach but which tree is it based on?
> Can you please let me know the base commit so that I can review the
> series properly?
last week's -tip/master
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel"
On 06/06/2013 05:49 AM, Tejun Heo wrote:
I generally agree with the approach but which tree is it based on?
Can you please let me know the base commit so that I can review the
series properly?
last week's -tip/master
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
On 05/29/2013 06:48 AM, Glauber Costa wrote:
> On 05/29/2013 04:23 AM, Andrew Morton wrote:
>> On Tue, 14 May 2013 16:38:38 +0400 Andrey Vagin wrote:
>>
>>> struct memcg_cache_params has a union. Different parts of this union are
>>> used for root and non-root ca
On 05/29/2013 06:48 AM, Glauber Costa wrote:
On 05/29/2013 04:23 AM, Andrew Morton wrote:
On Tue, 14 May 2013 16:38:38 +0400 Andrey Vagin ava...@openvz.org wrote:
struct memcg_cache_params has a union. Different parts of this union are
used for root and non-root caches. A part with destroying
-off-by: Tejun Heo
Cc: Peter Zijlstra
Cc: Glauber Costa
---
include/linux/cgroup.h | 1 +
kernel/cgroup.c| 3 ++-
2 files changed, 3 insertions(+), 1 deletion(-)
diff --git a/include/linux/cgroup.h b/include/linux/cgroup.h
index 5047355..5a8a093 100644
--- a/include/linux/cgroup.h
+++ b
on
top of which cpu can implement proper optimization.
[ glommer: don't call *_charge in stop_task.c ]
Signed-off-by: Tejun Heo
Signed-off-by: Glauber Costa
Cc: Peter Zijlstra
Cc: Michal Hocko
Cc: Kay Sievers
Cc: Lennart Poettering
Cc: Dave Jones
Cc: Ben Hutchings
Cc: Paul Turner
All the information we have that is needed for cpuusage (and
cpuusage_percpu) is present in schedstats. It is already recorded
in a sane hierarchical way.
If we have CONFIG_SCHEDSTATS, we don't really need to do any extra
work. All former functions become empty inlines.
Signed-off-by: Glauber
the independent hierarchy walk executed by
cpuacct.
Signed-off-by: Glauber Costa
CC: Dave Jones
CC: Ben Hutchings
CC: Peter Zijlstra
CC: Paul Turner
CC: Lennart Poettering
CC: Kay Sievers
CC: Tejun Heo
---
kernel/sched/rt.c| 1 +
kernel/sched/sched.h | 3 +++
2 files changed, 4 insertions
not likely, it seems a fair
price to pay.
2. Those figures do not include switches from and to the idle or stop
task. Those need to be recorded separately, which will happen in a
follow up patch.
Signed-off-by: Glauber Costa
CC: Peter Zijlstra
CC: Paul Turner
---
kernel/sched/fair.c | 18
air and rt classes are recorded in the root_task_group. One can easily
derive the total figure by adding those quantities together.
Signed-off-by: Glauber Costa
CC: Peter Zijlstra
CC: Paul Turner
---
kernel/sched/core.c | 17 +++--
kernel/sched/idle_task.c | 3 +++
kernel/sched/s
1996534 7205 1
cpu1 58800 0 1700 0 0 0 0 2848680 6510 1
cpu2 50500 0 1400 0 0 0 0 2350771 6183 1
cpu3 47200 0 1600 0 0 0 0 19766345 6277 2
Signed-off-by: Glauber Costa
CC: Peter Zijlstra
CC: Paul Turner
---
Documentation/cgroups/cpu.txt | 18 +++
kernel/sched/core.c
We already track multiple tick statistics per-cgroup, using
the task_group_account_field facility. This patch accounts
guest_time in that manner as well.
Signed-off-by: Glauber Costa
CC: Peter Zijlstra
CC: Paul Turner
---
kernel/sched/cputime.c | 10 --
1 file changed, 4 insertions
: incorporated mailing list feedback ]
Signed-off-by: Peter Zijlstra
Signed-off-by: Glauber Costa
---
kernel/sched/core.c | 20 +++-
kernel/sched/fair.c | 6 +-
kernel/sched/idle_task.c | 6 +-
kernel/sched/rt.c| 27 ---
kernel/sched
The CPU cgroup is so far, undocumented. Although data exists in the
Documentation directory about its functioning, it is usually spread,
and/or presented in the context of something else. This file
consolidates all cgroup-related information about it.
Signed-off-by: Glauber Costa
this call quite useless.
Signed-off-by: Glauber Costa
CC: Mike Galbraith
CC: Peter Zijlstra
CC: Thomas Gleixner
---
kernel/sched/stop_task.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/kernel/sched/stop_task.c b/kernel/sched/stop_task.c
index e08fbee..4142d7e 100644
--- a/kernel/sched
's patches that apparently got nowhere in the past.
Glauber Costa (8):
don't call cpuacct_charge in stop_task.c
sched: adjust exec_clock to use it as cpu usage metric
cpuacct: don't actually do anything.
sched: document the cpu cgroup.
sched: account guest time per-cgroup as well.
sched: record
got nowhere in the past.
Glauber Costa (8):
don't call cpuacct_charge in stop_task.c
sched: adjust exec_clock to use it as cpu usage metric
cpuacct: don't actually do anything.
sched: document the cpu cgroup.
sched: account guest time per-cgroup as well.
sched: record per-cgroup number
this call quite useless.
Signed-off-by: Glauber Costa glom...@openvz.org
CC: Mike Galbraith mgalbra...@suse.de
CC: Peter Zijlstra a.p.zijls...@chello.nl
CC: Thomas Gleixner t...@linutronix.de
---
kernel/sched/stop_task.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/kernel/sched/stop_task.c b
The CPU cgroup is so far, undocumented. Although data exists in the
Documentation directory about its functioning, it is usually spread,
and/or presented in the context of something else. This file
consolidates all cgroup-related information about it.
Signed-off-by: Glauber Costa glom
We already track multiple tick statistics per-cgroup, using
the task_group_account_field facility. This patch accounts
guest_time in that manner as well.
Signed-off-by: Glauber Costa glom...@openvz.org
CC: Peter Zijlstra a.p.zijls...@chello.nl
CC: Paul Turner p...@google.com
---
kernel/sched
.
[ glom...@openvz.org: incorporated mailing list feedback ]
Signed-off-by: Peter Zijlstra a.p.zijls...@chello.nl
Signed-off-by: Glauber Costa glom...@openvz.org
---
kernel/sched/core.c | 20 +++-
kernel/sched/fair.c | 6 +-
kernel/sched/idle_task.c | 6 +-
kernel
classes are recorded in the root_task_group. One can easily
derive the total figure by adding those quantities together.
Signed-off-by: Glauber Costa glom...@openvz.org
CC: Peter Zijlstra a.p.zijls...@chello.nl
CC: Paul Turner p...@google.com
---
kernel/sched/core.c | 17 +++--
kernel
1996534 7205 1
cpu1 58800 0 1700 0 0 0 0 2848680 6510 1
cpu2 50500 0 1400 0 0 0 0 2350771 6183 1
cpu3 47200 0 1600 0 0 0 0 19766345 6277 2
Signed-off-by: Glauber Costa glom...@openvz.org
CC: Peter Zijlstra a.p.zijls...@chello.nl
CC: Paul Turner p...@google.com
not likely, it seems a fair
price to pay.
2. Those figures do not include switches from and to the idle or stop
task. Those need to be recorded separately, which will happen in a
follow up patch.
Signed-off-by: Glauber Costa glom...@openvz.org
CC: Peter Zijlstra a.p.zijls...@chello.nl
CC: Paul
the independent hierarchy walk executed by
cpuacct.
Signed-off-by: Glauber Costa glom...@openvz.org
CC: Dave Jones da...@redhat.com
CC: Ben Hutchings b...@decadent.org.uk
CC: Peter Zijlstra a.p.zijls...@chello.nl
CC: Paul Turner p...@google.com
CC: Lennart Poettering lenn...@poettering.net
CC: Kay
and creating a base on
top of which cpu can implement proper optimization.
[ glommer: don't call *_charge in stop_task.c ]
Signed-off-by: Tejun Heo t...@kernel.org
Signed-off-by: Glauber Costa glom...@openvz.org
Cc: Peter Zijlstra pet...@infradead.org
Cc: Michal Hocko mho...@suse.cz
Cc: Kay Sievers
All the information we have that is needed for cpuusage (and
cpuusage_percpu) is present in schedstats. It is already recorded
in a sane hierarchical way.
If we have CONFIG_SCHEDSTATS, we don't really need to do any extra
work. All former functions become empty inlines.
Signed-off-by: Glauber
files.
Signed-off-by: Tejun Heo t...@kernel.org
Cc: Peter Zijlstra pet...@infradead.org
Cc: Glauber Costa glom...@openvz.org
---
include/linux/cgroup.h | 1 +
kernel/cgroup.c| 3 ++-
2 files changed, 3 insertions(+), 1 deletion(-)
diff --git a/include/linux/cgroup.h b/include/linux/cgroup.h
got nowhere in the past.
Glauber Costa (8):
don't call cpuacct_charge in stop_task.c
sched: adjust exec_clock to use it as cpu usage metric
cpuacct: don't actually do anything.
sched: document the cpu cgroup.
sched: account guest time per-cgroup as well.
sched: record per-cgroup number
this call quite useless.
Signed-off-by: Glauber Costa glom...@openvz.org
CC: Mike Galbraith mgalbra...@suse.de
CC: Peter Zijlstra a.p.zijls...@chello.nl
CC: Thomas Gleixner t...@linutronix.de
---
kernel/sched/stop_task.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/kernel/sched/stop_task.c b
the independent hierarchy walk executed by
cpuacct.
Signed-off-by: Glauber Costa glom...@openvz.org
CC: Dave Jones da...@redhat.com
CC: Ben Hutchings b...@decadent.org.uk
CC: Peter Zijlstra a.p.zijls...@chello.nl
CC: Paul Turner p...@google.com
CC: Lennart Poettering lenn...@poettering.net
CC: Kay
The CPU cgroup is so far, undocumented. Although data exists in the
Documentation directory about its functioning, it is usually spread,
and/or presented in the context of something else. This file
consolidates all cgroup-related information about it.
Signed-off-by: Glauber Costa glom
We already track multiple tick statistics per-cgroup, using
the task_group_account_field facility. This patch accounts
guest_time in that manner as well.
Signed-off-by: Glauber Costa glom...@openvz.org
CC: Peter Zijlstra a.p.zijls...@chello.nl
CC: Paul Turner p...@google.com
---
kernel/sched
.
[ glom...@openvz.org: incorporated mailing list feedback ]
Signed-off-by: Peter Zijlstra a.p.zijls...@chello.nl
Signed-off-by: Glauber Costa glom...@openvz.org
---
kernel/sched/core.c | 20 +++-
kernel/sched/fair.c | 6 +-
kernel/sched/idle_task.c | 6 +-
kernel
not likely, it seems a fair
price to pay.
2. Those figures do not include switches from and to the idle or stop
task. Those need to be recorded separately, which will happen in a
follow up patch.
Signed-off-by: Glauber Costa glom...@openvz.org
CC: Peter Zijlstra a.p.zijls...@chello.nl
CC: Paul
classes are recorded in the root_task_group. One can easily
derive the total figure by adding those quantities together.
Signed-off-by: Glauber Costa glom...@openvz.org
CC: Peter Zijlstra a.p.zijls...@chello.nl
CC: Paul Turner p...@google.com
---
kernel/sched/core.c | 17 +++--
kernel
1996534 7205 1
cpu1 58800 0 1700 0 0 0 0 2848680 6510 1
cpu2 50500 0 1400 0 0 0 0 2350771 6183 1
cpu3 47200 0 1600 0 0 0 0 19766345 6277 2
Signed-off-by: Glauber Costa glom...@openvz.org
CC: Peter Zijlstra a.p.zijls...@chello.nl
CC: Paul Turner p...@google.com
and creating a base on
top of which cpu can implement proper optimization.
[ glommer: don't call *_charge in stop_task.c ]
Signed-off-by: Tejun Heo t...@kernel.org
Signed-off-by: Glauber Costa glom...@openvz.org
Cc: Peter Zijlstra pet...@infradead.org
Cc: Michal Hocko mho...@suse.cz
Cc: Kay Sievers
All the information we have that is needed for cpuusage (and
cpuusage_percpu) is present in schedstats. It is already recorded
in a sane hierarchical way.
If we have CONFIG_SCHEDSTATS, we don't really need to do any extra
work. All former functions become empty inlines.
Signed-off-by: Glauber
files.
Signed-off-by: Tejun Heo t...@kernel.org
Cc: Peter Zijlstra pet...@infradead.org
Cc: Glauber Costa glom...@openvz.org
---
include/linux/cgroup.h | 1 +
kernel/cgroup.c| 3 ++-
2 files changed, 3 insertions(+), 1 deletion(-)
diff --git a/include/linux/cgroup.h b/include/linux/cgroup.h
On 05/29/2013 04:23 AM, Andrew Morton wrote:
> On Tue, 14 May 2013 16:38:38 +0400 Andrey Vagin wrote:
>
>> struct memcg_cache_params has a union. Different parts of this union are
>> used for root and non-root caches. A part with destroying work is used only
>> for non-root caches.
>
> That
On 05/29/2013 04:23 AM, Andrew Morton wrote:
On Tue, 14 May 2013 16:38:38 +0400 Andrey Vagin ava...@openvz.org wrote:
struct memcg_cache_params has a union. Different parts of this union are
used for root and non-root caches. A part with destroying work is used only
for non-root caches.
On 05/21/2013 11:17 AM, Pekka Enberg wrote:
> It seems to me relaxing the shrinker API restrictions and changing the
> "ret == -1" to "ret < 0" would be a much more robust approach...
Dave had already spoken against it, and I agree with him
Anybody returning any negative value different than -1
On 05/21/2013 11:17 AM, Pekka Enberg wrote:
It seems to me relaxing the shrinker API restrictions and changing the
ret == -1 to ret 0 would be a much more robust approach...
Dave had already spoken against it, and I agree with him
Anybody returning any negative value different than -1 is
(and it
is not clear if it will ever be)
With this patches, I can successfully run vzctl enter and ssh into containers
running totally unmodified kernels for: centos, ubuntu and suse.
Please comment
Glauber Costa (3):
hooks_ct: create devices inside container
allow for distro-specific fix ups at creation
From: Glauber Costa glom...@parallels.com
We will need that infrastucture when running with Linux upstream, since some
support is very unlikely to ever land in the Kernel. We need to do things like
account for the fact that udev may kick in and destroy all the setup we have
done for /dev. Since
side. We can do it from
the container side provided we do it before we chroot - and then the host side
fs is still visible.
The fact that we join a mount namespace will act to keep those mounts totally
private, and exempt us from cleaning it up.
Signed-off-by: Glauber Costa glom...@openvz.org
scripts.
Signed-off-by: Glauber Costa glom...@openvz.org
---
src/lib/hooks_ct.c | 44
1 file changed, 44 insertions(+)
diff --git a/src/lib/hooks_ct.c b/src/lib/hooks_ct.c
index f769865..a4f9425 100644
--- a/src/lib/hooks_ct.c
+++ b/src/lib/hooks_ct.c
On 05/21/2013 12:32 AM, Kir Kolyshkin wrote:
On 05/20/2013 05:49 AM, Glauber Costa wrote:
From: Glauber Costa glom...@parallels.com
We will need that infrastucture when running with Linux upstream,
since some
support is very unlikely to ever land in the Kernel. We need to do
things like
Kir,
Here is a new attempt at implementing fixups scripts.
They look nicer than the last version, and rely on a more
generic and configurable script instead, that should make
our lives a lot easier in the future.
Please let me know what you think
Glauber Costa (2):
allow for distro-specific
/.autofsck. We
can check if the file was modified (non-existent - existent, or different
modification time) and run our fixups after this.
Signed-off-by: Glauber Costa glom...@openvz.org
---
etc/dists/scripts/prestart.sh | 36
1 file changed, 36 insertions
On 05/19/2013 09:41 PM, Kir Kolyshkin wrote:
+ */
+#define VZ_DEFAULT_UID10
+#define VZ_DEFAULT_GID10
I assume these are no longer used, right?
right
___
Devel mailing list
Devel@openvz.org
From: Glauber Costa glom...@parallels.com
We will need that infrastucture when running with Linux upstream, since some
support is very unlikely to ever land in the Kernel. We need to do things like
account for the fact that udev may kick in and destroy all the setup we have
done for /dev. Since
+{
+char buf[STR_SIZE];
+
+/* Distributions that don't need the fixup will can stop right
here */
+if (!actions || !actions-ct_fixup)
+return 0;
+
+if (snprintf(buf, sizeof(buf), %s/%s, root,
/etc/rc3.d/S00vz-fixups.sh) 0)
Again and again :(
How this snprintf
On 05/17/2013 04:18 AM, Kir Kolyshkin wrote:
+stat(res-fs.private, private_stat);
+if ((local_uid (private_stat.st_uid != *local_uid)) ||
+(local_gid (private_stat.st_gid != *local_gid))) {
As I just commented at the very end of a previous patch,
indeed it does
On 05/17/2013 04:11 AM, Kir Kolyshkin wrote:
+if ((arg-userns_p != -1) (read(arg-userns_p, ret,
sizeof(ret)) != sizeof(ret))) {
+logger(-1, errno, Cannot read from user namespace pipe);
We don't close arg-userns_p in case of error here.
And it seems we do not close the other
On 05/17/2013 05:35 AM, Kir Kolyshkin wrote:
This is kinda becoming over-engineered (and now I realized I should have
said it earlier,
when reviewing the patch that added the first param).
I understand well why you need local_uid and local_gid from config and
cmdline
in ct_open(), but
will go back to it
ASAP.
Glauber Costa (6):
user namespace support for upstream containers
add user mismatch test
allow local uid and gid to be specified at container creation
modify tar extraction to account for user namespace
automatically add bridge venet0 when needed
allow for distro
From: Glauber Costa glom...@parallels.com
This patch allows the execution of unprivileged containers running ontop
of an upstream Linux Kernel. We will run at whatever UID is found in the
configuration file (so far empty, thus disabled).
Signed-off-by: Glauber Costa glom...@parallels.com
From: Glauber Costa glom...@parallels.com
In theory, we won't be able to run if our private area is not owned by
ourselves. We could, if it have very wide open security permissions, but we
should never set up a container like that.
Aside from a basic sanity check, this is intended to catch
From: Glauber Costa glom...@parallels.com
It is a valid use case to run a container with host uid and gid different than
the default. In particular, already deployed versions of vzctl are expected to
have this value unset, effectively meaning they are not expecting user
namespaces to be present
From: Glauber Costa glom...@parallels.com
If we are running upstream with user namespaces, we need to create the
container filesystem not with the ownership preserved, but reflecting the
mapping we need to apply. Note that according to our documentation, we should
ignore this if the user
From: Glauber Costa glom...@parallels.com
The chosen architecture to deal with --ipadd with upstream containers is to
create a veth pair and add the host side information to a bridge called venet0.
This way, all the code that expects venet0 to exist can still work without
modifications
From: Glauber Costa glom...@parallels.com
We will need that infrastucture when running with Linux upstream, since some
support is very unlikely to ever land in the Kernel. We need to do things like
account for the fact that udev may kick in and destroy all the setup we have
done for /dev. Since
On 05/16/2013 12:20 PM, Oskar Andero wrote:
> On 16:49 Wed 15 May , Glauber Costa wrote:
>> On 05/15/2013 06:47 PM, Oskar Andero wrote:
>>> On 16:18 Wed 15 May , Glauber Costa wrote:
>>>> On 05/15/2013 06:10 PM, Oskar Andero wrote:
>>>>>
On 05/16/2013 12:20 PM, Oskar Andero wrote:
On 16:49 Wed 15 May , Glauber Costa wrote:
On 05/15/2013 06:47 PM, Oskar Andero wrote:
On 16:18 Wed 15 May , Glauber Costa wrote:
On 05/15/2013 06:10 PM, Oskar Andero wrote:
On 17:03 Tue 14 May , Glauber Costa wrote:
On 05/13/2013 06:16
On 05/16/2013 04:14 PM, Andrey Vagin wrote:
+ ret = ct_env_create_real(arg);
+ if (ret 0)
return VZ_RESOURCE_ERROR;
- }
Isn't it better to just keep the return values intact in create_real,
and then return them as is if ret != 0 ?
On 05/16/2013 04:14 PM, Andrey Vagin wrote:
CRIU requires a pid of the init.
Signed-off-by: Andrey Vagin ava...@openvz.org
The way you coded it, it seems to me that we will always overwrite the
pid file, which is fine: this way we won't run into the usual pid file
already exists kinds of
On 05/15/2013 06:47 PM, Oskar Andero wrote:
> On 16:18 Wed 15 May , Glauber Costa wrote:
>> On 05/15/2013 06:10 PM, Oskar Andero wrote:
>>> On 17:03 Tue 14 May , Glauber Costa wrote:
>>>> On 05/13/2013 06:16 PM, Oskar Andero wrote:
>>>>> Hi,
On 05/15/2013 06:10 PM, Oskar Andero wrote:
> On 17:03 Tue 14 May , Glauber Costa wrote:
>> On 05/13/2013 06:16 PM, Oskar Andero wrote:
>>> Hi,
>>>
>>> In a previous discussion on lkml it was noted that the shrinkers use the
>>> magic v
_soft_reclaim_eligible should therefore stop climbing up the
> hierarchy at B (root of the memory pressure).
>
> Changes since v1
> - add sc->target_mem_cgroup handling into mem_cgroup_soft_reclaim_eligible
>
> Signed-off-by: Michal Hocko
> ---
Reviewed-by: Glau
emcontrol.c | 224
> +--
> 1 file changed, 1 insertion(+), 223 deletions(-)
Great =)
Reviewed-by: Glauber Costa
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://v
_shrink_zone doesn't return the number of shrunk groups as nr_scanned
> test covers both no groups scanned and no pages from the required zone
> as pointed by Johannes
>
> Signed-off-by: Michal Hocko
Patch looks fine to me
Reviewed-by: Glauber Costa
--
To unsubscribe from this
as pointed by Johannes
Signed-off-by: Michal Hocko mho...@suse.cz
Patch looks fine to me
Reviewed-by: Glauber Costa glom...@openvz.org
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http
+--
1 file changed, 1 insertion(+), 223 deletions(-)
Great =)
Reviewed-by: Glauber Costa glom...@openvz.org
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org
sc-target_mem_cgroup handling into mem_cgroup_soft_reclaim_eligible
Signed-off-by: Michal Hocko mho...@suse.cz
---
Reviewed-by: Glauber Costa glom...@openvz.org
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More
On 05/15/2013 06:10 PM, Oskar Andero wrote:
On 17:03 Tue 14 May , Glauber Costa wrote:
On 05/13/2013 06:16 PM, Oskar Andero wrote:
Hi,
In a previous discussion on lkml it was noted that the shrinkers use the
magic value -1 to signal that something went wrong.
This patch-set implements
On 05/15/2013 06:47 PM, Oskar Andero wrote:
On 16:18 Wed 15 May , Glauber Costa wrote:
On 05/15/2013 06:10 PM, Oskar Andero wrote:
On 17:03 Tue 14 May , Glauber Costa wrote:
On 05/13/2013 06:16 PM, Oskar Andero wrote:
Hi,
In a previous discussion on lkml it was noted
On 05/13/2013 06:16 PM, Oskar Andero wrote:
> Hi,
>
> In a previous discussion on lkml it was noted that the shrinkers use the
> magic value "-1" to signal that something went wrong.
>
> This patch-set implements the suggestion of instead using errno.h values
> to return something more
On 05/14/2013 06:44 PM, Michal Hocko wrote:
> On Tue 14-05-13 16:40:31, Michal Hocko wrote:
>> On Tue 14-05-13 16:38:38, Andrey Vagin wrote:
>>> struct memcg_cache_params has a union. Different parts of this union are
>>> used for root and non-root caches. A part with destroying work is used only
On 05/14/2013 06:44 PM, Michal Hocko wrote:
On Tue 14-05-13 16:40:31, Michal Hocko wrote:
On Tue 14-05-13 16:38:38, Andrey Vagin wrote:
struct memcg_cache_params has a union. Different parts of this union are
used for root and non-root caches. A part with destroying work is used only
for
On 05/13/2013 06:16 PM, Oskar Andero wrote:
Hi,
In a previous discussion on lkml it was noted that the shrinkers use the
magic value -1 to signal that something went wrong.
This patch-set implements the suggestion of instead using errno.h values
to return something more meaningful.
The
On 05/14/2013 07:02 AM, Kir Kolyshkin wrote:
Oh my, four cases of whitespace-at-eol which I had to fixed manually.
Sorry about that. I think I got to used to checkpatch and the such that
I forget to verify all of those manually.
Wanted to apply it nevertheless and fix some things myself, but
101 - 200 of 3816 matches
Mail list logo
