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
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 da5eb5b..fda1cbe 100644
--- a/kernel/sched
On 11/20/2012 11:05 AM, Kamezawa Hiroyuki wrote:
> (2012/11/20 14:31), Tejun Heo wrote:
>> Hello, Kamezawa.
>>
>> On Tue, Nov 20, 2012 at 01:34:54PM +0900, Kamezawa Hiroyuki wrote:
>>> I'm sorry if I misunderstand ... current usage of css-id in
>>> memory/swap cgroup
>>> is for recording
On 11/20/2012 11:05 AM, Kamezawa Hiroyuki wrote:
(2012/11/20 14:31), Tejun Heo wrote:
Hello, Kamezawa.
On Tue, Nov 20, 2012 at 01:34:54PM +0900, Kamezawa Hiroyuki wrote:
I'm sorry if I misunderstand ... current usage of css-id in
memory/swap cgroup
is for recording information of memory
this call quite useless.
Signed-off-by: Glauber Costa glom...@parallels.com
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
files.
Signed-off-by: Tejun Heo t...@kernel.org
Cc: Peter Zijlstra pet...@infradead.org
Cc: Glauber Costa glom...@parallels.com
---
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
the independent hierarchy walk executed by
cpuacct.
Signed-off-by: Glauber Costa glom...@parallels.com
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
.
I didn't do so, because I believe we care more about setups that would enable
a bunch of options anyway - which is likely to include SCHEDSTATS. Custom setups
can take a much easier route and just compile out the whole thing! But let me
know if I should do it.
Glauber Costa (3):
don't call
Zijlstra pet...@infradead.org
Cc: Glauber Costa glom...@parallels.com
Cc: Michal Hocko mho...@suse.cz
Cc: Kay Sievers kay.siev...@vrfy.org
Cc: Lennart Poettering mzxre...@0pointer.de
Cc: Dave Jones da...@redhat.com
Cc: Ben Hutchings b...@decadent.org.uk
Cc: Paul Turner p...@google.com
---
init
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...@parallels.com
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
with this as well.
Acked-by: Glauber Costa glom...@parallels.com
--
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/majordomo-info.html
Please read the FAQ at http
On 11/12/2012 03:37 PM, Mel Gorman wrote:
diff --git a/include/linux/gfp.h b/include/linux/gfp.h
index 02c1c971..d0a7967 100644
--- a/include/linux/gfp.h
+++ b/include/linux/gfp.h
@@ -31,6 +31,7 @@ struct vm_area_struct;
#define ___GFP_THISNODE 0x4u
#define
the others untouched, it looks correct.
Acked-by: Glauber Costa glom...@parallels.com
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
On 11/20/2012 01:57 AM, Marcelo Tosatti wrote:
This patchset, based on earlier work by Jeremy Fitzhardinge, implements
paravirtual clock vsyscall support.
It should be possible to implement Xen support relatively easily.
It reduces clock_gettime from 500 cycles to 200 cycles
on my
>>> Umm, why do users of cpusets not want to be able to trigger memory
>>> pressure notifications?
>>>
>> Because cpusets only deal with memory placement, not memory usage.
>
> The set of nodes that a thread is allowed to allocate from may face memory
> pressure up to and including oom while
On 11/17/2012 05:21 AM, Anton Vorontsov wrote:
> On Fri, Nov 16, 2012 at 01:57:09PM -0800, David Rientjes wrote:
I'm wondering if we should have more than three different levels.
>>>
>>> In the case I outlined below, for backwards compatibility. What I
>>> actually mean is that memcg
On 11/17/2012 01:57 AM, David Rientjes wrote:
> On Sat, 17 Nov 2012, Glauber Costa wrote:
>
>>> I'm wondering if we should have more than three different levels.
>>>
>>
>> In the case I outlined below, for backwards compatibility. What I
>> actually mean
On 11/17/2012 01:57 AM, David Rientjes wrote:
On Sat, 17 Nov 2012, Glauber Costa wrote:
I'm wondering if we should have more than three different levels.
In the case I outlined below, for backwards compatibility. What I
actually mean is that memcg *currently* allows arbitrary notifications
On 11/17/2012 05:21 AM, Anton Vorontsov wrote:
On Fri, Nov 16, 2012 at 01:57:09PM -0800, David Rientjes wrote:
I'm wondering if we should have more than three different levels.
In the case I outlined below, for backwards compatibility. What I
actually mean is that memcg *currently* allows
Umm, why do users of cpusets not want to be able to trigger memory
pressure notifications?
Because cpusets only deal with memory placement, not memory usage.
The set of nodes that a thread is allowed to allocate from may face memory
pressure up to and including oom while the rest of the
Hey,
On 11/17/2012 12:04 AM, David Rientjes wrote:
> On Fri, 16 Nov 2012, Glauber Costa wrote:
>
>> My personal take:
>>
>> Most people hate memcg due to the cost it imposes. I've already
>> demonstrated that with some effort, it doesn't necessarily have to be
&
On 11/16/2012 06:55 PM, Michal Hocko wrote:
> On Fri 16-11-12 16:21:59, KAMEZAWA Hiroyuki wrote:
>> (2012/11/16 16:11), Glauber Costa wrote:
>>> On 11/16/2012 09:07 AM, Kamezawa Hiroyuki wrote:
>>>> (2012/11/15 22:47), Glauber Costa wrote:
>>>>> On
On 11/16/2012 01:25 AM, David Rientjes wrote:
> On Thu, 15 Nov 2012, Anton Vorontsov wrote:
>
>> Hehe, you're saying that we have to have cgroups=y. :) But some folks were
>> deliberately asking us to make the cgroups optional.
>>
>
> Enabling just CONFIG_CGROUPS (which is enabled by default)
On 11/16/2012 01:25 AM, David Rientjes wrote:
On Thu, 15 Nov 2012, Anton Vorontsov wrote:
Hehe, you're saying that we have to have cgroups=y. :) But some folks were
deliberately asking us to make the cgroups optional.
Enabling just CONFIG_CGROUPS (which is enabled by default) and no other
On 11/16/2012 06:55 PM, Michal Hocko wrote:
On Fri 16-11-12 16:21:59, KAMEZAWA Hiroyuki wrote:
(2012/11/16 16:11), Glauber Costa wrote:
On 11/16/2012 09:07 AM, Kamezawa Hiroyuki wrote:
(2012/11/15 22:47), Glauber Costa wrote:
On 11/15/2012 01:41 PM, Kamezawa Hiroyuki wrote:
(2012/11/15 11:54
Hey,
On 11/17/2012 12:04 AM, David Rientjes wrote:
On Fri, 16 Nov 2012, Glauber Costa wrote:
My personal take:
Most people hate memcg due to the cost it imposes. I've already
demonstrated that with some effort, it doesn't necessarily have to be
so. (http://lwn.net/Articles/517634
On 11/16/2012 09:07 AM, Kamezawa Hiroyuki wrote:
> (2012/11/15 22:47), Glauber Costa wrote:
>> On 11/15/2012 01:41 PM, Kamezawa Hiroyuki wrote:
>>> (2012/11/15 11:54), Glauber Costa wrote:
>>>> The idea is to synchronously do it, leaving it up to the shrinki
On 11/15/2012 01:41 PM, Kamezawa Hiroyuki wrote:
> (2012/11/15 11:54), Glauber Costa wrote:
>> The idea is to synchronously do it, leaving it up to the shrinking
>> facilities in vmscan.c and/or others. Not actively retrying shrinking
>> may leave the caches alive for more tim
On 11/15/2012 01:41 PM, Kamezawa Hiroyuki wrote:
(2012/11/15 11:54), Glauber Costa wrote:
The idea is to synchronously do it, leaving it up to the shrinking
facilities in vmscan.c and/or others. Not actively retrying shrinking
may leave the caches alive for more time, but it will remove
On 11/16/2012 09:07 AM, Kamezawa Hiroyuki wrote:
(2012/11/15 22:47), Glauber Costa wrote:
On 11/15/2012 01:41 PM, Kamezawa Hiroyuki wrote:
(2012/11/15 11:54), Glauber Costa wrote:
The idea is to synchronously do it, leaving it up to the shrinking
facilities in vmscan.c and/or others
.
There is no such guarantee with per cpu areas, therefore move
to memblock_alloc based allocation.
Ok.
Signed-off-by: Marcelo Tosatti mtosa...@redhat.com
For the concept:
Acked-by: Glauber Costa glom...@parallels.com
I do have one comment.
Index: vsyscall/arch/x86/kernel/kvmclock.c
On 11/15/2012 04:08 AM, Marcelo Tosatti wrote:
Originally from Jeremy Fitzhardinge.
So code can be reused.
Signed-off-by: Marcelo Tosatti mtosa...@redhat.com
I thought I had acked this one already?
But maybe I didn't...
Acked-by: Glauber Costa glom...@parallels.com
--
To unsubscribe
On 11/15/2012 04:08 AM, Marcelo Tosatti wrote:
Signed-off-by: Marcelo Tosatti mtosa...@redhat.com
Index: vsyscall/arch/x86/kernel/pvclock.c
===
--- vsyscall.orig/arch/x86/kernel/pvclock.c
Acked-by: Glauber Costa glom
On 11/15/2012 04:08 AM, Marcelo Tosatti wrote:
As noted by Gleb, not advertising SSE2 support implies
no RDTSC barriers.
Signed-off-by: Marcelo Tosatti mtosa...@redhat.com
And this gets a separate patch because?
Index: vsyscall/arch/x86/include/asm/pvclock.h
tricky...
Assuming you tested this change in at least one stable tsc and one
unstable tsc system:
Acked-by: Glauber Costa glom...@parallels.com
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at http
.
There is no such guarantee with per cpu areas, therefore move
to memblock_alloc based allocation.
Signed-off-by: Marcelo Tosatti mtosa...@redhat.com
No further objections.
Acked-by: Glauber Costa glom...@parallels.com
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body
On 11/14/2012 10:55 PM, Tejun Heo wrote:
> Hello, Glauber.
>
> On Wed, Nov 14, 2012 at 03:05:46PM +0400, Glauber Costa wrote:
>> Will memcontrol.c need similar amendments?
>>
>> The code that lives in -mm and includes kmemcg includes the following
>> exc
As suggested by akpm, change the manual initialization of our kmem
index to DEFINE_IDA()
Signed-off-by: Glauber Costa
CC: Michal Hocko
CC: Kamezawa Hiroyuki
CC: Johannes Weiner
CC: Andrew Morton
---
mm/memcontrol.c | 5 +
1 file changed, 1 insertion(+), 4 deletions(-)
diff --git a/mm
Signed-off-by: Glauber Costa
Reported-by: Sasha Levin
CC: Michal Hocko
CC: Kamezawa Hiroyuki
CC: Johannes Weiner
CC: Andrew Morton
CC: Christoph Lameter
CC: Pekka Enberg
---
mm/slub.c | 13 -
1 file changed, 12 insertions(+), 1 deletion(-)
diff --git a/mm/slub.c b/mm/slub.c
, it is because we don't need that memory yet.
Signed-off-by: Glauber Costa
CC: Michal Hocko
CC: Kamezawa Hiroyuki
CC: Johannes Weiner
CC: Andrew Morton
---
include/linux/slab.h | 2 +-
mm/memcontrol.c | 17 +++--
2 files changed, 8 insertions(+), 11 deletions(-)
diff --git
testing as we can in memcontrol.h to
give the compiler the option to inline it, but won't force it.
I tested this with 4.7.2, it will inline all three functions anyway when
compiling with -O2, and will refrain from it when compiling with -Os.
This seems like a good behavior.
Signed-off-by: Glauber Costa
-by: Glauber Costa
CC: Michal Hocko
CC: Kamezawa Hiroyuki
CC: Johannes Weiner
CC: Andrew Morton
---
include/linux/memcontrol.h | 6 ++
mm/slab.c | 1 +
mm/slub.c | 21 +
3 files changed, 24 insertions(+), 4 deletions(-)
diff --git
if there is anything you would like to see different, and
sorry for not handling this earlier.
Glauber Costa (7):
memcg: simplify ida initialization
move include of workqueue.h to top of slab.h file
memcg: remove test for current->mm in memcg_stop/resume_kmem_account
memcg: repl
Suggested by akpm. I originally decided to put it closer to the use of
the work struct, but let's move it to top.
Signed-off-by: Glauber Costa
CC: Michal Hocko
CC: Kamezawa Hiroyuki
CC: Johannes Weiner
CC: Andrew Morton
---
include/linux/slab.h | 4 ++--
1 file changed, 2 insertions(+), 2
of a
comment explaining why current->mm test is needed, my proposal in this
patch is to remove memcg_stop/resume_account from the worker thread and
make sure all callers have a valid mm context.
Signed-off-by: Glauber Costa
CC: Michal Hocko
CC: Kamezawa Hiroyuki
CC: Johannes Weiner
CC: Andrew Mor
On 11/14/2012 10:41 PM, Tejun Heo wrote:
> Hello, Glauber.
>
> On Wed, Nov 14, 2012 at 05:17:51PM +0100, Glauber Costa wrote:
>> Why can't we reuse the scheduler iterator and move it to kernel/cgroup.c
>> ? It already exists, provide sane ordering, and only relies on parent
&
On 11/09/2012 07:37 AM, Sasha Levin wrote:
> On 11/08/2012 01:51 AM, Glauber Costa wrote:
>> On 11/07/2012 04:53 PM, Sasha Levin wrote:
>>> On 11/01/2012 08:07 AM, Glauber Costa wrote:
>>>> SLUB allows us to tune a particular cache behavior with sysfs-based
>&
On 11/13/2012 07:01 AM, Tejun Heo wrote:
> cgroup->dentry is marked and used as a RCU pointer; however, it isn't
> one - the final dentry put doesn't go through call_rcu(). cgroup and
> dentry share the same RCU freeing rule via synchronize_rcu() in
> cgroup_diput() (kfree_rcu() used on cgrp is
p_subsys->post_clone().
>
> Loosely based on Glauber's "generalize post_clone into post_create"
> patch.
>
> Signed-off-by: Tejun Heo
> Original-patch-by: Glauber Costa
> Original-patch: <1351686554-22592-2-git-send-email-glom...@parallels.com>
> Cc: Gla
On 11/13/2012 04:30 PM, Michal Hocko wrote:
> Hi all,
> this patch set tries to make mem_cgroup_iter saner in the way how it
> walks hierarchies. css->id based traversal is far from being ideal as it
> is not deterministic because it depends on the creation ordering.
>
> Diffstat looks promising
On 11/13/2012 04:30 PM, Michal Hocko wrote:
Hi all,
this patch set tries to make mem_cgroup_iter saner in the way how it
walks hierarchies. css-id based traversal is far from being ideal as it
is not deterministic because it depends on the creation ordering.
Diffstat looks promising but it
on Glauber's generalize post_clone into post_create
patch.
Signed-off-by: Tejun Heo t...@kernel.org
Original-patch-by: Glauber Costa glom...@parallels.com
Original-patch: 1351686554-22592-2-git-send-email-glom...@parallels.com
Cc: Glauber Costa glom...@parallels.com
I don't have any preference one
On 11/13/2012 07:01 AM, Tejun Heo wrote:
cgroup-dentry is marked and used as a RCU pointer; however, it isn't
one - the final dentry put doesn't go through call_rcu(). cgroup and
dentry share the same RCU freeing rule via synchronize_rcu() in
cgroup_diput() (kfree_rcu() used on cgrp is
On 11/09/2012 07:37 AM, Sasha Levin wrote:
On 11/08/2012 01:51 AM, Glauber Costa wrote:
On 11/07/2012 04:53 PM, Sasha Levin wrote:
On 11/01/2012 08:07 AM, Glauber Costa wrote:
SLUB allows us to tune a particular cache behavior with sysfs-based
tunables. When creating a new memcg cache copy
On 11/14/2012 10:41 PM, Tejun Heo wrote:
Hello, Glauber.
On Wed, Nov 14, 2012 at 05:17:51PM +0100, Glauber Costa wrote:
Why can't we reuse the scheduler iterator and move it to kernel/cgroup.c
? It already exists, provide sane ordering, and only relies on parent
information - which cgroup
Suggested by akpm. I originally decided to put it closer to the use of
the work struct, but let's move it to top.
Signed-off-by: Glauber Costa glom...@parallels.com
CC: Michal Hocko mho...@suse.cz
CC: Kamezawa Hiroyuki kamezawa.hir...@jp.fujitsu.com
CC: Johannes Weiner han...@cmpxchg.org
CC
of a
comment explaining why current-mm test is needed, my proposal in this
patch is to remove memcg_stop/resume_account from the worker thread and
make sure all callers have a valid mm context.
Signed-off-by: Glauber Costa glom...@parallels.com
CC: Michal Hocko mho...@suse.cz
CC: Kamezawa Hiroyuki
if there is anything you would like to see different, and
sorry for not handling this earlier.
Glauber Costa (7):
memcg: simplify ida initialization
move include of workqueue.h to top of slab.h file
memcg: remove test for current-mm in memcg_stop/resume_kmem_account
memcg: replace
-by: Glauber Costa glom...@parallels.com
CC: Michal Hocko mho...@suse.cz
CC: Kamezawa Hiroyuki kamezawa.hir...@jp.fujitsu.com
CC: Johannes Weiner han...@cmpxchg.org
CC: Andrew Morton a...@linux-foundation.org
---
include/linux/memcontrol.h | 6 ++
mm/slab.c | 1 +
mm/slub.c
testing as we can in memcontrol.h to
give the compiler the option to inline it, but won't force it.
I tested this with 4.7.2, it will inline all three functions anyway when
compiling with -O2, and will refrain from it when compiling with -Os.
This seems like a good behavior.
Signed-off-by: Glauber Costa
, it is because we don't need that memory yet.
Signed-off-by: Glauber Costa glom...@parallels.com
CC: Michal Hocko mho...@suse.cz
CC: Kamezawa Hiroyuki kamezawa.hir...@jp.fujitsu.com
CC: Johannes Weiner han...@cmpxchg.org
CC: Andrew Morton a...@linux-foundation.org
---
include/linux/slab.h | 2 +-
mm
+0x3e/0x90
[ 351.960334] [83a993aa] int_signal+0x12/0x17
Signed-off-by: Glauber Costa glom...@parallels.com
Reported-by: Sasha Levin sasha.le...@oracle.com
CC: Michal Hocko mho...@suse.cz
CC: Kamezawa Hiroyuki kamezawa.hir...@jp.fujitsu.com
CC: Johannes Weiner han...@cmpxchg.org
CC: Andrew
As suggested by akpm, change the manual initialization of our kmem
index to DEFINE_IDA()
Signed-off-by: Glauber Costa glom...@parallels.com
CC: Michal Hocko mho...@suse.cz
CC: Kamezawa Hiroyuki kamezawa.hir...@jp.fujitsu.com
CC: Johannes Weiner han...@cmpxchg.org
CC: Andrew Morton a...@linux
On 11/14/2012 10:55 PM, Tejun Heo wrote:
Hello, Glauber.
On Wed, Nov 14, 2012 at 03:05:46PM +0400, Glauber Costa wrote:
Will memcontrol.c need similar amendments?
The code that lives in -mm and includes kmemcg includes the following
excerpt:
rcu_read_lock();
dentry
On 11/09/2012 06:22 PM, Tejun Heo wrote:
> Hey, Daniel.
>
> On Fri, Nov 09, 2012 at 12:09:38PM +0100, Daniel Wagner wrote:
>> On 08.11.2012 20:07, Tejun Heo wrote:> Subject: cgroup: add
>> cgroup_subsys->post_create()
>>>
>>> Currently, there's no way for a controller to find out whether a new
On 11/09/2012 06:22 PM, Tejun Heo wrote:
Hey, Daniel.
On Fri, Nov 09, 2012 at 12:09:38PM +0100, Daniel Wagner wrote:
On 08.11.2012 20:07, Tejun Heo wrote: Subject: cgroup: add
cgroup_subsys-post_create()
Currently, there's no way for a controller to find out whether a new
cgroup finished
On 11/08/2012 08:21 PM, Andrew Morton wrote:
> On Thu, 8 Nov 2012 17:15:36 +
> Christoph Lameter wrote:
>
>> On Wed, 7 Nov 2012, Andrew Morton wrote:
>>
>>> What's up with kmem_cache_shrink? It's global and exported to modules
>>> but its only external caller is some weird and hopelessly
On 11/08/2012 08:21 PM, Andrew Morton wrote:
On Thu, 8 Nov 2012 17:15:36 +
Christoph Lameter c...@linux.com wrote:
On Wed, 7 Nov 2012, Andrew Morton wrote:
What's up with kmem_cache_shrink? It's global and exported to modules
but its only external caller is some weird and hopelessly
On 11/07/2012 11:46 PM, Andrew Morton wrote:
> On Wed, 7 Nov 2012 10:22:17 +0100
> Glauber Costa wrote:
>
>>>>> container synchronously. If those objects are normally left floating
>>>>> around in an allocated but reclaimable state then we can address t
On 11/07/2012 04:53 PM, Sasha Levin wrote:
> On 11/01/2012 08:07 AM, Glauber Costa wrote:
>> SLUB allows us to tune a particular cache behavior with sysfs-based
>> tunables. When creating a new memcg cache copy, we'd like to preserve
>> any tunables the parent cache alread
On 11/07/2012 08:16 AM, Andrew Morton wrote:
> On Wed, 7 Nov 2012 08:13:08 +0100 Glauber Costa wrote:
>
>> On 11/06/2012 01:48 AM, Andrew Morton wrote:
>>> On Thu, 1 Nov 2012 16:07:41 +0400
>>> Glauber Costa wrote:
>>>
>>>> This mea
On 11/07/2012 08:16 AM, Andrew Morton wrote:
On Wed, 7 Nov 2012 08:13:08 +0100 Glauber Costa glom...@parallels.com wrote:
On 11/06/2012 01:48 AM, Andrew Morton wrote:
On Thu, 1 Nov 2012 16:07:41 +0400
Glauber Costa glom...@parallels.com wrote:
This means that when we destroy a memcg cache
On 11/07/2012 04:53 PM, Sasha Levin wrote:
On 11/01/2012 08:07 AM, Glauber Costa wrote:
SLUB allows us to tune a particular cache behavior with sysfs-based
tunables. When creating a new memcg cache copy, we'd like to preserve
any tunables the parent cache already had.
This can be done
On 11/07/2012 11:46 PM, Andrew Morton wrote:
On Wed, 7 Nov 2012 10:22:17 +0100
Glauber Costa glom...@parallels.com wrote:
container synchronously. If those objects are normally left floating
around in an allocated but reclaimable state then we can address that
by synchronously freeing them
On 11/06/2012 01:48 AM, Andrew Morton wrote:
> On Thu, 1 Nov 2012 16:07:41 +0400
> Glauber Costa wrote:
>
>> This means that when we destroy a memcg cache that happened to be empty,
>> those caches may take a lot of time to go away: removing the memcg
>> reference w
On 11/06/2012 01:23 AM, Andrew Morton wrote:
> On Thu, 1 Nov 2012 16:07:34 +0400
> Glauber Costa wrote:
>
>> Every cache that is considered a root cache (basically the "original" caches,
>> tied to the root memcg/no-memcg) will have an array that should be large
On 11/06/2012 01:28 AM, Andrew Morton wrote:
> On Thu, 1 Nov 2012 16:07:35 +0400
> Glauber Costa wrote:
>
>> +static __always_inline struct kmem_cache *
>> +memcg_kmem_get_cache(struct kmem_cache *cachep, gfp_t gfp)
>
> I still don't understand why this code u
On 11/06/2012 01:28 AM, Andrew Morton wrote:
On Thu, 1 Nov 2012 16:07:35 +0400
Glauber Costa glom...@parallels.com wrote:
+static __always_inline struct kmem_cache *
+memcg_kmem_get_cache(struct kmem_cache *cachep, gfp_t gfp)
I still don't understand why this code uses __always_inline so
On 11/06/2012 01:23 AM, Andrew Morton wrote:
On Thu, 1 Nov 2012 16:07:34 +0400
Glauber Costa glom...@parallels.com wrote:
Every cache that is considered a root cache (basically the original caches,
tied to the root memcg/no-memcg) will have an array that should be large
enough
to store
On 11/06/2012 01:48 AM, Andrew Morton wrote:
On Thu, 1 Nov 2012 16:07:41 +0400
Glauber Costa glom...@parallels.com wrote:
This means that when we destroy a memcg cache that happened to be empty,
those caches may take a lot of time to go away: removing the memcg
reference won't destroy them
e cgroup is linked into the generic cgroup hierarchy.
> This plays the counterpart of ->pre_destroy().
>
> Signed-off-by: Tejun Heo
> Cc: Glauber Costa
Tejun, If we do it this way, we end up with two callbacks that are
called after create: post_clone and post_create. I myself p
On 11/02/2012 08:25 PM, JoonSoo Kim wrote:
> Hello, Glauber.
>
> 2012/11/2 Glauber Costa :
>> On 11/02/2012 04:04 AM, Andrew Morton wrote:
>>> On Thu, 1 Nov 2012 16:07:16 +0400
>>> Glauber Costa wrote:
>>>
>>>> Hi,
>>>>
>&g
On 11/03/2012 12:06 AM, Tejun Heo wrote:
> Hey, Joonsoo.
>
> On Sat, Nov 03, 2012 at 04:25:59AM +0900, JoonSoo Kim wrote:
>> I am worrying about data cache footprint which is possibly caused by
>> this patchset, especially slab implementation.
>> If there are several memcg cgroups, each cgroup
On 11/03/2012 12:06 AM, Tejun Heo wrote:
Hey, Joonsoo.
On Sat, Nov 03, 2012 at 04:25:59AM +0900, JoonSoo Kim wrote:
I am worrying about data cache footprint which is possibly caused by
this patchset, especially slab implementation.
If there are several memcg cgroups, each cgroup has it's
On 11/02/2012 08:25 PM, JoonSoo Kim wrote:
Hello, Glauber.
2012/11/2 Glauber Costa glom...@parallels.com:
On 11/02/2012 04:04 AM, Andrew Morton wrote:
On Thu, 1 Nov 2012 16:07:16 +0400
Glauber Costa glom...@parallels.com wrote:
Hi,
This work introduces the kernel memory controller
the counterpart of -pre_destroy().
Signed-off-by: Tejun Heo t...@kernel.org
Cc: Glauber Costa glom...@parallels.com
Tejun, If we do it this way, we end up with two callbacks that are
called after create: post_clone and post_create. I myself prefer the
approach I took, that convert post_clone
On 11/02/2012 05:00 PM, Marcelo Tosatti wrote:
On Fri, Nov 02, 2012 at 02:23:06PM +0400, Glauber Costa wrote:
On 11/02/2012 01:39 AM, Marcelo Tosatti wrote:
On Thu, Nov 01, 2012 at 06:28:31PM +0400, Glauber Costa wrote:
On 11/01/2012 02:47 AM, Marcelo Tosatti wrote:
Allow a guest to register
On 11/02/2012 04:05 AM, Andrew Morton wrote:
> On Thu, 1 Nov 2012 16:07:27 +0400
> Glauber Costa wrote:
>
>> Because the ultimate goal of the kmem tracking in memcg is to track slab
>> pages as well, we can't guarantee that we'll always be able to point a
>> p
On 11/02/2012 04:05 AM, Andrew Morton wrote:
> On Thu, 1 Nov 2012 16:07:39 +0400
> Glauber Costa wrote:
>
>> This patch implements destruction of memcg caches. Right now,
>> only caches where our reference counter is the last remaining are
>> deleted. If there are a
On 11/02/2012 04:04 AM, Andrew Morton wrote:
> On Thu, 1 Nov 2012 16:07:16 +0400
> Glauber Costa wrote:
>
>> Hi,
>>
>> This work introduces the kernel memory controller for memcg. Unlike previous
>> submissions, this includes the whole controller, comprised of s
On 11/02/2012 04:04 AM, Andrew Morton wrote:
On Thu, 1 Nov 2012 16:07:16 +0400
Glauber Costa glom...@parallels.com wrote:
Hi,
This work introduces the kernel memory controller for memcg. Unlike previous
submissions, this includes the whole controller, comprised of slab and stack
memory
On 11/02/2012 04:05 AM, Andrew Morton wrote:
On Thu, 1 Nov 2012 16:07:39 +0400
Glauber Costa glom...@parallels.com wrote:
This patch implements destruction of memcg caches. Right now,
only caches where our reference counter is the last remaining are
deleted. If there are any other
On 11/02/2012 04:05 AM, Andrew Morton wrote:
On Thu, 1 Nov 2012 16:07:27 +0400
Glauber Costa glom...@parallels.com wrote:
Because the ultimate goal of the kmem tracking in memcg is to track slab
pages as well, we can't guarantee that we'll always be able to point a
page to a particular
On 11/01/2012 02:47 AM, Marcelo Tosatti wrote:
+ info = pvclock_get_vsyscall_time_info(cpu);
+
+ low = (int)__pa(info) | 1;
+ high = ((u64)__pa(per_cpu(hv_clock, cpu)) 32);
+ ret = native_write_msr_safe(MSR_KVM_USERSPACE_TIME, low, high);
+ printk(KERN_INFO kvm-clock:
On 10/31/2012 07:12 AM, Marcelo Tosatti wrote:
On Tue, Oct 30, 2012 at 11:39:32AM +0200, Avi Kivity wrote:
On 10/29/2012 08:40 PM, Marcelo Tosatti wrote:
On Mon, Oct 29, 2012 at 10:44:41AM -0700, Jeremy Fitzhardinge wrote:
On 10/29/2012 07:45 AM, Glauber Costa wrote:
On 10/24/2012 05:13 PM
On 11/02/2012 01:39 AM, Marcelo Tosatti wrote:
On Thu, Nov 01, 2012 at 06:28:31PM +0400, Glauber Costa wrote:
On 11/01/2012 02:47 AM, Marcelo Tosatti wrote:
Allow a guest to register a second location for the VCPU time info
structure for each vcpu (as described by MSR_KVM_SYSTEM_TIME_NEW
On 11/02/2012 04:33 AM, Marcelo Tosatti wrote:
On Thu, Nov 01, 2012 at 07:42:43PM -0200, Marcelo Tosatti wrote:
On Thu, Nov 01, 2012 at 06:41:46PM +0400, Glauber Costa wrote:
On 11/01/2012 02:47 AM, Marcelo Tosatti wrote:
+#ifdef CONFIG_PARAVIRT_CLOCK
+
+static notrace const struct
This is just a cleanup patch for clarity of expression. In earlier
submissions, people asked it to be in a separate patch, so here it is.
[ v2: use named enum as type throughout the file as well ]
Signed-off-by: Glauber Costa
Acked-by: Kamezawa Hiroyuki
Acked-by: Michal Hocko
Acked
o the user memory)
[ v4: make kmem files part of the main array;
do not allow limit to be set for non-empty cgroups ]
[ v5: cosmetic changes ]
[ v6: name changes and reorganizations, moved memcg_propagate_kmem ]
Signed-off-by: Glauber Costa
Acked-by: Kamezawa Hiroyuki
Acked-by: Michal
601 - 700 of 3816 matches
Mail list logo
