On Mon, Mar 25 2013, Greg Thelen wrote:
> On Mon, Mar 25 2013, Dave Chinner wrote:
>
>> On Mon, Mar 25, 2013 at 05:39:13PM -0700, Greg Thelen wrote:
>>> On Mon, Mar 25 2013, Dave Chinner wrote:
>>> > On Mon, Mar 25, 2013 at 10:22:31AM -0700, Greg Thelen wrote
On Mon, Mar 25 2013, Greg Thelen wrote:
On Mon, Mar 25 2013, Dave Chinner wrote:
On Mon, Mar 25, 2013 at 05:39:13PM -0700, Greg Thelen wrote:
On Mon, Mar 25 2013, Dave Chinner wrote:
On Mon, Mar 25, 2013 at 10:22:31AM -0700, Greg Thelen wrote:
Call cond_resched() from shrink_dentry_list
On Mon, Mar 25 2013, Dave Chinner wrote:
> On Mon, Mar 25, 2013 at 05:39:13PM -0700, Greg Thelen wrote:
>> On Mon, Mar 25 2013, Dave Chinner wrote:
>> > On Mon, Mar 25, 2013 at 10:22:31AM -0700, Greg Thelen wrote:
>> >> Call cond_resched() from sh
On Mon, Mar 25 2013, Dave Chinner wrote:
> On Mon, Mar 25, 2013 at 10:22:31AM -0700, Greg Thelen wrote:
>> Call cond_resched() from shrink_dentry_list() to preserve
>> shrink_dcache_parent() interactivity.
>>
>> void shrink_dcache_parent(struct dentry * parent)
system("rm -rf x");
if (gettimeofday(, NULL))
err(1, "gettimeofday");
diff = (((double)t2.tv_sec * 100 + t2.tv_usec) -
((double)t1.tv_sec * 100 + t1.tv_usec));
printf(
))
err(1, gettimeofday);
diff = (((double)t2.tv_sec * 100 + t2.tv_usec) -
((double)t1.tv_sec * 100 + t1.tv_usec));
printf(done: %g elapsed\n, diff/1e6);
return 0;
}
Signed-off-by: Greg Thelen gthe
On Mon, Mar 25 2013, Dave Chinner wrote:
On Mon, Mar 25, 2013 at 10:22:31AM -0700, Greg Thelen wrote:
Call cond_resched() from shrink_dentry_list() to preserve
shrink_dcache_parent() interactivity.
void shrink_dcache_parent(struct dentry * parent)
{
while ((found = select_parent
On Mon, Mar 25 2013, Dave Chinner wrote:
On Mon, Mar 25, 2013 at 05:39:13PM -0700, Greg Thelen wrote:
On Mon, Mar 25 2013, Dave Chinner wrote:
On Mon, Mar 25, 2013 at 10:22:31AM -0700, Greg Thelen wrote:
Call cond_resched() from shrink_dentry_list() to preserve
shrink_dcache_parent
On Wed, Feb 27 2013, Roman Gushchin wrote:
> Hi, all!
>
> I've implemented low limits for memory cgroups. The primary goal was to add
> an ability
> to protect some memory from reclaiming without using mlock(). A kind of "soft
> mlock()".
>
> I think this patch will be helpful when it's
On Wed, Feb 27 2013, Roman Gushchin wrote:
Hi, all!
I've implemented low limits for memory cgroups. The primary goal was to add
an ability
to protect some memory from reclaiming without using mlock(). A kind of soft
mlock().
I think this patch will be helpful when it's necessary to
unt -t tmpfs -o mpol=interleave,mpol=interleave,size=100M nodev /mnt
umount /mnt
done
This patch fixes all of the above. I could have broken the patch into
three pieces but is seemed easier to review as one.
Signed-off-by: Greg Thelen
---
mm/shmem.c | 12 +---
1 file changed
back further.
Signed-off-by: Greg Thelen
---
mm/shmem.c | 10 --
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git a/mm/shmem.c b/mm/shmem.c
index 5dd56f6..efd0b3a 100644
--- a/mm/shmem.c
+++ b/mm/shmem.c
@@ -2487,6 +2487,7 @@ static int shmem_remount_fs(struct super_block *sb,
further.
Signed-off-by: Greg Thelen gthe...@google.com
---
mm/shmem.c | 10 --
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git a/mm/shmem.c b/mm/shmem.c
index 5dd56f6..efd0b3a 100644
--- a/mm/shmem.c
+++ b/mm/shmem.c
@@ -2487,6 +2487,7 @@ static int shmem_remount_fs(struct
tmpfs -o mpol=interleave,mpol=interleave,size=100M nodev /mnt
umount /mnt
done
This patch fixes all of the above. I could have broken the patch into
three pieces but is seemed easier to review as one.
Signed-off-by: Greg Thelen gthe...@google.com
---
mm/shmem.c | 12 +---
1
On Tue, Feb 12 2013, Anton Vorontsov wrote:
> Hi Greg,
>
> Thanks for taking a look!
>
> On Tue, Feb 12, 2013 at 10:42:51PM -0800, Greg Thelen wrote:
> [...]
>> > +static bool vmpressure_event(struct vmpressure *vmpr,
>> > +
On Tue, Feb 12 2013, Anton Vorontsov wrote:
Hi Greg,
Thanks for taking a look!
On Tue, Feb 12, 2013 at 10:42:51PM -0800, Greg Thelen wrote:
[...]
+static bool vmpressure_event(struct vmpressure *vmpr,
+ unsigned long s, unsigned long r)
+{
+ struct
On Sun, Feb 10 2013, Anton Vorontsov wrote:
> With this patch userland applications that want to maintain the
> interactivity/memory allocation cost can use the new pressure level
> notifications. The levels are defined like this:
>
> The "low" level means that the system is reclaiming memory for
On Sun, Feb 10 2013, Anton Vorontsov wrote:
With this patch userland applications that want to maintain the
interactivity/memory allocation cost can use the new pressure level
notifications. The levels are defined like this:
The low level means that the system is reclaiming memory for new
On Tue, Feb 05 2013, Michal Hocko wrote:
> On Tue 05-02-13 10:09:57, Greg Thelen wrote:
>> On Tue, Feb 05 2013, Michal Hocko wrote:
>>
>> > On Tue 05-02-13 08:48:23, Greg Thelen wrote:
>> >> On Tue, Feb 05 2013, Michal Hocko wrote:
>> >>
On Tue, Feb 05 2013, Michal Hocko wrote:
On Tue 05-02-13 10:09:57, Greg Thelen wrote:
On Tue, Feb 05 2013, Michal Hocko wrote:
On Tue 05-02-13 08:48:23, Greg Thelen wrote:
On Tue, Feb 05 2013, Michal Hocko wrote:
On Tue 05-02-13 15:49:47, azurIt wrote:
[...]
Just to be sure
On Tue, Feb 05 2013, Michal Hocko wrote:
> On Tue 05-02-13 08:48:23, Greg Thelen wrote:
>> On Tue, Feb 05 2013, Michal Hocko wrote:
>>
>> > On Tue 05-02-13 15:49:47, azurIt wrote:
>> > [...]
>> >> Just to be sure - am i supposed to apply this two p
On Tue, Feb 05 2013, Michal Hocko wrote:
> On Tue 05-02-13 15:49:47, azurIt wrote:
> [...]
>> Just to be sure - am i supposed to apply this two patches?
>> http://watchdog.sk/lkml/patches/
>
> 5-memcg-fix-1.patch is not complete. It doesn't contain the folloup I
> mentioned in a follow up email.
On Tue, Feb 05 2013, Michal Hocko wrote:
On Tue 05-02-13 15:49:47, azurIt wrote:
[...]
Just to be sure - am i supposed to apply this two patches?
http://watchdog.sk/lkml/patches/
5-memcg-fix-1.patch is not complete. It doesn't contain the folloup I
mentioned in a follow up email. Here is
On Tue, Feb 05 2013, Michal Hocko wrote:
On Tue 05-02-13 08:48:23, Greg Thelen wrote:
On Tue, Feb 05 2013, Michal Hocko wrote:
On Tue 05-02-13 15:49:47, azurIt wrote:
[...]
Just to be sure - am i supposed to apply this two patches?
http://watchdog.sk/lkml/patches/
5-memcg-fix-1
On Mon, Jan 07 2013, Tejun Heo wrote:
> On Fri, Jan 04, 2013 at 01:05:18PM -0800, Greg Thelen wrote:
>> If the command line parameter cannot
>> be opened, then cgroup_event_listener prints an error message and
>> tries to return an error. However, due to an uninitialized v
On Mon, Jan 07 2013, Tejun Heo wrote:
On Fri, Jan 04, 2013 at 01:05:18PM -0800, Greg Thelen wrote:
If the absolute-path-to-control-file command line parameter cannot
be opened, then cgroup_event_listener prints an error message and
tries to return an error. However, due to an uninitialized
; incrementing (2):
> __set_page_dirty
> __set_page_dirty_nobuffers
> decrementing (2):
> clear_page_dirty_for_io
> cancel_dirty_page
>
> To prevent AB/BA deadlock mentioned by Greg Thelen in previous version
>
On Tue, Dec 25 2012, Sha Zhengju wrote:
> From: Sha Zhengju
>
> Similar to dirty page, we add per cgroup writeback pages accounting. The lock
> rule still is:
> mem_cgroup_begin_update_page_stat()
> modify page WRITEBACK stat
> mem_cgroup_update_page_stat()
>
On Tue, Dec 25 2012, Sha Zhengju wrote:
From: Sha Zhengju handai@taobao.com
Similar to dirty page, we add per cgroup writeback pages accounting. The lock
rule still is:
mem_cgroup_begin_update_page_stat()
modify page WRITEBACK stat
mem_cgroup_update_page_stat()
):
clear_page_dirty_for_io
cancel_dirty_page
To prevent AB/BA deadlock mentioned by Greg Thelen in previous version
(https://lkml.org/lkml/2012/7/30/227), we adjust the lock order:
-private_lock -- mapping-tree_lock -- memcg-move_lock.
So we need to make mapping
this:
$ gcc -Wall -O2 cgroup_event_listener.c
cgroup_event_listener.c: In function ‘main’:
cgroup_event_listener.c:109:2: warning: ‘ret’ may be used uninitialized in
this function [-Wuninitialized]
Signed-off-by: Greg Thelen
---
tools/cgroup/cgroup_event_listener.c |2 +-
1 files changed, 1
Move the cgroup_event_listener.c tool from Documentation into the new
tools/cgroup directory.
This change involves wiring cgroup_event_listener.c into the tools/
make system so that is can be built with:
$ make tools/cgroup
Signed-off-by: Greg Thelen
---
Documentation/cgroups/00-INDEX
Move the cgroup_event_listener.c tool from Documentation into the new
tools/cgroup directory.
This change involves wiring cgroup_event_listener.c into the tools/
make system so that is can be built with:
$ make tools/cgroup
Signed-off-by: Greg Thelen gthe...@google.com
---
Documentation
.
Compiler warning found this:
$ gcc -Wall -O2 cgroup_event_listener.c
cgroup_event_listener.c: In function ‘main’:
cgroup_event_listener.c:109:2: warning: ‘ret’ may be used uninitialized in
this function [-Wuninitialized]
Signed-off-by: Greg Thelen gthe...@google.com
---
tools/cgroup
remove from the wait queue.
Signed-off-by: Greg Thelen
Signed-off-by: Aaron Durbin
---
kernel/cgroup.c | 11 ---
1 files changed, 8 insertions(+), 3 deletions(-)
diff --git a/kernel/cgroup.c b/kernel/cgroup.c
index ece60d4..a0d75bb 100644
--- a/kernel/cgroup.c
+++ b/kernel/cg
Use list_del_init() rather than list_del() to remove events from
cgrp->event_list. No functional change. This is just defensive
coding.
Signed-off-by: Greg Thelen
---
kernel/cgroup.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/kernel/cgroup.c b/kernel/cgrou
On Wed, Nov 28 2012, Tejun Heo wrote:
> Hello, Greg.
>
> On Wed, Nov 28, 2012 at 12:15:42PM -0800, Greg Thelen wrote:
>> @@ -4276,6 +4276,7 @@ static int cgroup_destroy_locked(struct cgroup *cgrp)
>> DEFINE_WAIT(wait);
>> struct cgroup_event *event, *tmp;
&
remove from the wait queue.
Signed-off-by: Greg Thelen
Signed-off-by: Aaron Durbin
---
kernel/cgroup.c | 11 ---
1 files changed, 8 insertions(+), 3 deletions(-)
diff --git a/kernel/cgroup.c b/kernel/cgroup.c
index ece60d4..c79a969 100644
--- a/kernel/cgroup.c
+++ b/kernel/cg
zation
before insertion.
Signed-off-by: Greg Thelen
---
kernel/cgroup.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/kernel/cgroup.c b/kernel/cgroup.c
index 01d5342..ece60d4 100644
--- a/kernel/cgroup.c
+++ b/kernel/cgroup.c
@@ -1394,6 +1394,7 @@ static void init_cgrou
insertion.
Signed-off-by: Greg Thelen gthe...@google.com
---
kernel/cgroup.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/kernel/cgroup.c b/kernel/cgroup.c
index 01d5342..ece60d4 100644
--- a/kernel/cgroup.c
+++ b/kernel/cgroup.c
@@ -1394,6 +1394,7 @@ static void
from the wait queue.
Signed-off-by: Greg Thelen gthe...@google.com
Signed-off-by: Aaron Durbin adur...@google.com
---
kernel/cgroup.c | 11 ---
1 files changed, 8 insertions(+), 3 deletions(-)
diff --git a/kernel/cgroup.c b/kernel/cgroup.c
index ece60d4..c79a969 100644
--- a/kernel
On Wed, Nov 28 2012, Tejun Heo wrote:
Hello, Greg.
On Wed, Nov 28, 2012 at 12:15:42PM -0800, Greg Thelen wrote:
@@ -4276,6 +4276,7 @@ static int cgroup_destroy_locked(struct cgroup *cgrp)
DEFINE_WAIT(wait);
struct cgroup_event *event, *tmp;
struct cgroup_subsys *ss
Use list_del_init() rather than list_del() to remove events from
cgrp-event_list. No functional change. This is just defensive
coding.
Signed-off-by: Greg Thelen gthe...@google.com
---
kernel/cgroup.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/kernel/cgroup.c b
from the wait queue.
Signed-off-by: Greg Thelen gthe...@google.com
Signed-off-by: Aaron Durbin adur...@google.com
---
kernel/cgroup.c | 11 ---
1 files changed, 8 insertions(+), 3 deletions(-)
diff --git a/kernel/cgroup.c b/kernel/cgroup.c
index ece60d4..a0d75bb 100644
--- a/kernel
We ran some netperf comparisons measuring the overhead of enabling
CONFIG_MEMCG_KMEM with a kmem limit. Short answer: no regression seen.
This is a multiple machine (client,server) netperf test. Both client
and server machines were running the same kernel with the same
configuration.
A
We ran some netperf comparisons measuring the overhead of enabling
CONFIG_MEMCG_KMEM with a kmem limit. Short answer: no regression seen.
This is a multiple machine (client,server) netperf test. Both client
and server machines were running the same kernel with the same
configuration.
A
Since 628f423553 "memcg: limit change shrink usage" both
res_counter_write() and write_strategy_fn have been unused. This
patch deletes them both.
Signed-off-by: Greg Thelen
---
include/linux/res_counter.h |5 -
kernel/res_counter.c| 22 --
2 fil
Since 628f423553 memcg: limit change shrink usage both
res_counter_write() and write_strategy_fn have been unused. This
patch deletes them both.
Signed-off-by: Greg Thelen gthe...@google.com
---
include/linux/res_counter.h |5 -
kernel/res_counter.c| 22
On Wed, Nov 07 2012, Kirill A. Shutemov wrote:
> On Wed, Nov 07, 2012 at 02:53:49AM -0800, Anton Vorontsov wrote:
>> Hi all,
>>
>> This is the third RFC. As suggested by Minchan Kim, the API is much
>> simplified now (comparing to vmevent_fd):
>>
>> - As well as Minchan, KOSAKI Motohiro didn't
On Wed, Nov 07 2012, Kirill A. Shutemov wrote:
On Wed, Nov 07, 2012 at 02:53:49AM -0800, Anton Vorontsov wrote:
Hi all,
This is the third RFC. As suggested by Minchan Kim, the API is much
simplified now (comparing to vmevent_fd):
- As well as Minchan, KOSAKI Motohiro didn't like the
Herbert could suggest
>> testing approaches.
>>
>
> I can test it, but unfortunately I am unlikely to get to prepare a good
> environment before Barcelona.
>
> I know, however, that Greg Thelen was testing netperf in his setup.
> Greg, do you have any publishable numbers
please determine what impact this has upon networking?
I expect Eric Dumazet, Dave Miller and Tom Herbert could suggest
testing approaches.
I can test it, but unfortunately I am unlikely to get to prepare a good
environment before Barcelona.
I know, however, that Greg Thelen was testing
On Thu, Aug 23 2012, Glauber Costa wrote:
> On 08/23/2012 03:23 AM, Greg Thelen wrote:
>> On Wed, Aug 22 2012, Glauber Costa wrote:
>>
>>>>>>
>>>>>> I am fine with either, I just need a clear sign from you guys so I don't
>>>>>&g
On Thu, Aug 23 2012, Glauber Costa wrote:
On 08/23/2012 03:23 AM, Greg Thelen wrote:
On Wed, Aug 22 2012, Glauber Costa wrote:
I am fine with either, I just need a clear sign from you guys so I don't
keep deimplementing and reimplementing this forever.
I would be for make it simple now
On Wed, Aug 22 2012, Glauber Costa wrote:
> On 08/22/2012 01:50 AM, Greg Thelen wrote:
>> On Thu, Aug 09 2012, Glauber Costa wrote:
>>
>>> This patch introduces infrastructure for tracking kernel memory pages to
>>> a given memcg. This will happen when
On Wed, Aug 22 2012, Glauber Costa wrote:
I am fine with either, I just need a clear sign from you guys so I don't
keep deimplementing and reimplementing this forever.
>>>
>>> I would be for make it simple now and go with additional features later
>>> when there is a demand for
On Wed, Aug 22 2012, Glauber Costa wrote:
I am fine with either, I just need a clear sign from you guys so I don't
keep deimplementing and reimplementing this forever.
I would be for make it simple now and go with additional features later
when there is a demand for them. Maybe we will have
On Wed, Aug 22 2012, Glauber Costa wrote:
On 08/22/2012 01:50 AM, Greg Thelen wrote:
On Thu, Aug 09 2012, Glauber Costa wrote:
This patch introduces infrastructure for tracking kernel memory pages to
a given memcg. This will happen whenever the caller includes the flag
__GFP_KMEMCG flag
On Tue, Aug 21 2012, Michal Hocko wrote:
> On Tue 21-08-12 13:22:09, Glauber Costa wrote:
>> On 08/21/2012 11:54 AM, Michal Hocko wrote:
> [...]
>> > But maybe you have a good use case for that?
>> >
>> Honestly, I don't. For my particular use case, this would be always on,
>> and end of story.
On Thu, Aug 09 2012, Glauber Costa wrote:
> This patch introduces infrastructure for tracking kernel memory pages to
> a given memcg. This will happen whenever the caller includes the flag
> __GFP_KMEMCG flag, and the task belong to a memcg other than the root.
>
> In memcontrol.h those functions
On Thu, Aug 09 2012, Glauber Costa wrote:
This patch introduces infrastructure for tracking kernel memory pages to
a given memcg. This will happen whenever the caller includes the flag
__GFP_KMEMCG flag, and the task belong to a memcg other than the root.
In memcontrol.h those functions are
On Tue, Aug 21 2012, Michal Hocko wrote:
On Tue 21-08-12 13:22:09, Glauber Costa wrote:
On 08/21/2012 11:54 AM, Michal Hocko wrote:
[...]
But maybe you have a good use case for that?
Honestly, I don't. For my particular use case, this would be always on,
and end of story. I was
On Wed, Aug 15 2012, Glauber Costa wrote:
> On 08/15/2012 09:12 PM, Greg Thelen wrote:
>> On Wed, Aug 15 2012, Glauber Costa wrote:
>>
>>> On 08/15/2012 08:38 PM, Greg Thelen wrote:
>>>> On Wed, Aug 15 2012, Glauber Costa wrote:
>>>>
>>>&g
On Wed, Aug 15 2012, Glauber Costa wrote:
> On 08/15/2012 08:38 PM, Greg Thelen wrote:
>> On Wed, Aug 15 2012, Glauber Costa wrote:
>>
>>> On 08/14/2012 10:58 PM, Greg Thelen wrote:
>>>> On Mon, Aug 13 2012, Glauber Costa wrote:
>>>>
On Wed, Aug 15 2012, Glauber Costa wrote:
> On 08/14/2012 10:58 PM, Greg Thelen wrote:
>> On Mon, Aug 13 2012, Glauber Costa wrote:
>>
>>>>>> +WARN_ON(mem_cgroup_is_root(memcg));
>>>>>> +size = (1 << order) <&
On Wed, Aug 15 2012, Christoph Lameter wrote:
> On Wed, 15 Aug 2012, Michal Hocko wrote:
>
>> > That is not what the kernel does, in general. We assume that if he wants
>> > that memory and we can serve it, we should. Also, not all kernel memory
>> > is unreclaimable. We can shrink the slabs, for
On Wed, Aug 15 2012, Christoph Lameter wrote:
On Wed, 15 Aug 2012, Michal Hocko wrote:
That is not what the kernel does, in general. We assume that if he wants
that memory and we can serve it, we should. Also, not all kernel memory
is unreclaimable. We can shrink the slabs, for instance.
On Wed, Aug 15 2012, Glauber Costa wrote:
On 08/14/2012 10:58 PM, Greg Thelen wrote:
On Mon, Aug 13 2012, Glauber Costa wrote:
+WARN_ON(mem_cgroup_is_root(memcg));
+size = (1 order) PAGE_SHIFT;
+memcg_uncharge_kmem(memcg, size);
+mem_cgroup_put(memcg
On Wed, Aug 15 2012, Glauber Costa wrote:
On 08/15/2012 08:38 PM, Greg Thelen wrote:
On Wed, Aug 15 2012, Glauber Costa wrote:
On 08/14/2012 10:58 PM, Greg Thelen wrote:
On Mon, Aug 13 2012, Glauber Costa wrote:
+ WARN_ON(mem_cgroup_is_root(memcg));
+ size = (1 order
On Wed, Aug 15 2012, Glauber Costa wrote:
On 08/15/2012 09:12 PM, Greg Thelen wrote:
On Wed, Aug 15 2012, Glauber Costa wrote:
On 08/15/2012 08:38 PM, Greg Thelen wrote:
On Wed, Aug 15 2012, Glauber Costa wrote:
On 08/14/2012 10:58 PM, Greg Thelen wrote:
On Mon, Aug 13 2012, Glauber
On Mon, Aug 13 2012, Glauber Costa wrote:
>>> > + WARN_ON(mem_cgroup_is_root(memcg));
>>> > + size = (1 << order) << PAGE_SHIFT;
>>> > + memcg_uncharge_kmem(memcg, size);
>>> > + mem_cgroup_put(memcg);
>> Why do we need ref-counting here ? kmem res_counter cannot work as
>> reference ?
> This is
On Mon, Aug 13 2012, Glauber Costa wrote:
+ WARN_ON(mem_cgroup_is_root(memcg));
+ size = (1 order) PAGE_SHIFT;
+ memcg_uncharge_kmem(memcg, size);
+ mem_cgroup_put(memcg);
Why do we need ref-counting here ? kmem res_counter cannot work as
reference ?
This is of course the pair of the
On Mon, Aug 13 2012, Glauber Costa wrote:
>>
>> Here's the dmesg splat.
>>
>
> Do you always get this report in the same way?
> I managed to get a softirq inconsistency like yours, but the complaint
> goes for a different lock.
Yes, I repeatedly get the same dmesg splat below.
Once I your
On Mon, Aug 13 2012, Glauber Costa wrote:
Here's the dmesg splat.
Do you always get this report in the same way?
I managed to get a softirq inconsistency like yours, but the complaint
goes for a different lock.
Yes, I repeatedly get the same dmesg splat below.
Once I your 'execute the
On Thu, Aug 09 2012, Glauber Costa wrote:
> This patch introduces infrastructure for tracking kernel memory pages to
> a given memcg. This will happen whenever the caller includes the flag
> __GFP_KMEMCG flag, and the task belong to a memcg other than the root.
>
> In memcontrol.h those functions
On Thu, Aug 09 2012, Glauber Costa wrote:
> When a process tries to allocate a page with the __GFP_KMEMCG flag, the
> page allocator will call the corresponding memcg functions to validate
> the allocation. Tasks in the root memcg can always proceed.
>
> To avoid adding markers to the page - and
On Thu, Aug 09 2012, Glauber Costa wrote:
When a process tries to allocate a page with the __GFP_KMEMCG flag, the
page allocator will call the corresponding memcg functions to validate
the allocation. Tasks in the root memcg can always proceed.
To avoid adding markers to the page - and a
On Thu, Aug 09 2012, Glauber Costa wrote:
This patch introduces infrastructure for tracking kernel memory pages to
a given memcg. This will happen whenever the caller includes the flag
__GFP_KMEMCG flag, and the task belong to a memcg other than the root.
In memcontrol.h those functions are
On Thu, Aug 09 2012, Glauber Costa wrote:
> When a process tries to allocate a page with the __GFP_KMEMCG flag, the
> page allocator will call the corresponding memcg functions to validate
> the allocation. Tasks in the root memcg can always proceed.
>
> To avoid adding markers to the page - and
On Thu, Aug 09 2012, Glauber Costa wrote:
When a process tries to allocate a page with the __GFP_KMEMCG flag, the
page allocator will call the corresponding memcg functions to validate
the allocation. Tasks in the root memcg can always proceed.
To avoid adding markers to the page - and a
On Fri, Jul 27 2012, Sha Zhengju wrote:
> From: Sha Zhengju
>
> Similar to dirty page, we add per cgroup writeback pages accounting. The lock
> rule still is:
> mem_cgroup_begin_update_page_stat()
> modify page WRITEBACK stat
> mem_cgroup_update_page_stat()
>
On Fri, Jul 27 2012, Sha Zhengju wrote:
> From: Sha Zhengju
>
> This patch adds memcg routines to count dirty pages, which allows memory
> controller
> to maintain an accurate view of the amount of its dirty memory and can
> provide some
> info for users while group's direct reclaim is
On Fri, Jul 27 2012, Sha Zhengju wrote:
From: Sha Zhengju handai@taobao.com
This patch adds memcg routines to count dirty pages, which allows memory
controller
to maintain an accurate view of the amount of its dirty memory and can
provide some
info for users while group's direct
On Fri, Jul 27 2012, Sha Zhengju wrote:
From: Sha Zhengju handai@taobao.com
Similar to dirty page, we add per cgroup writeback pages accounting. The lock
rule still is:
mem_cgroup_begin_update_page_stat()
modify page WRITEBACK stat
mem_cgroup_update_page_stat()
On Thu, Jun 28 2012, Sha Zhengju wrote:
> From: Sha Zhengju
>
> Similar to dirty page, we add per cgroup writeback pages accounting. The lock
> rule still is:
> mem_cgroup_begin_update_page_stat()
> modify page WRITEBACK stat
> mem_cgroup_update_page_stat()
>
On Thu, Jun 28 2012, Sha Zhengju wrote:
> From: Sha Zhengju
>
> This patch adds memcg routines to count dirty pages, which allows memory
> controller
> to maintain an accurate view of the amount of its dirty memory and can
> provide some
> info for users while group's direct reclaim is
sync. So it
might help to add a comment to both indicating their relationship so we
don't accidentally modify the enum without updating the dependent string
table.
Otherwise, looks good.
Reviewed-by: Greg Thelen
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel"
modify the enum without updating the dependent string
table.
Otherwise, looks good.
Reviewed-by: Greg Thelen gthe...@google.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
On Thu, Jun 28 2012, Sha Zhengju wrote:
From: Sha Zhengju handai@taobao.com
This patch adds memcg routines to count dirty pages, which allows memory
controller
to maintain an accurate view of the amount of its dirty memory and can
provide some
info for users while group's direct
On Thu, Jun 28 2012, Sha Zhengju wrote:
From: Sha Zhengju handai@taobao.com
Similar to dirty page, we add per cgroup writeback pages accounting. The lock
rule still is:
mem_cgroup_begin_update_page_stat()
modify page WRITEBACK stat
mem_cgroup_update_page_stat()
301 - 390 of 390 matches
Mail list logo
