2011-03-18 12:54:36

by Namhyung Kim

[permalink] [raw]
Subject: [PATCH 1/3] memcg: mark init_section_page_cgroup() properly

The commit ca371c0d7e23 ("memcg: fix page_cgroup fatal error
in FLATMEM") removes call to alloc_bootmem() in the function
so that it can be marked as __meminit to reduce memory usage
when MEMORY_HOTPLUG=n.

Signed-off-by: Namhyung Kim <[email protected]>
Cc: KAMEZAWA Hiroyuki <[email protected]>
---
mm/page_cgroup.c | 3 +--
1 files changed, 1 insertions(+), 2 deletions(-)

diff --git a/mm/page_cgroup.c b/mm/page_cgroup.c
index 5bffada7cde1..2d1a0fa01d7b 100644
--- a/mm/page_cgroup.c
+++ b/mm/page_cgroup.c
@@ -105,8 +105,7 @@ struct page_cgroup *lookup_page_cgroup(struct page *page)
return section->page_cgroup + pfn;
}

-/* __alloc_bootmem...() is protected by !slab_available() */
-static int __init_refok init_section_page_cgroup(unsigned long pfn)
+static int __meminit init_section_page_cgroup(unsigned long pfn)
{
struct mem_section *section = __pfn_to_section(pfn);
struct page_cgroup *base, *pc;
--
1.7.4


2011-03-18 12:54:47

by Namhyung Kim

[permalink] [raw]
Subject: [PATCH 2/3] memcg: fix off-by-one when calculating swap cgroup map length

It allocated one more page than necessary if @max_pages was
a multiple of SC_PER_PAGE.

Signed-off-by: Namhyung Kim <[email protected]>
Cc: KAMEZAWA Hiroyuki <[email protected]>
---
mm/page_cgroup.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/mm/page_cgroup.c b/mm/page_cgroup.c
index 2d1a0fa01d7b..29951abc852e 100644
--- a/mm/page_cgroup.c
+++ b/mm/page_cgroup.c
@@ -446,7 +446,7 @@ int swap_cgroup_swapon(int type, unsigned long max_pages)
if (!do_swap_account)
return 0;

- length = ((max_pages/SC_PER_PAGE) + 1);
+ length = DIV_ROUND_UP(max_pages, SC_PER_PAGE);
array_size = length * sizeof(void *);

array = vmalloc(array_size);
--
1.7.4

2011-03-18 12:54:50

by Namhyung Kim

[permalink] [raw]
Subject: [PATCH 3/3] memcg: move page-freeing code outside of lock

Signed-off-by: Namhyung Kim <[email protected]>
Cc: KAMEZAWA Hiroyuki <[email protected]>
---
mm/page_cgroup.c | 22 +++++++++++++---------
1 files changed, 13 insertions(+), 9 deletions(-)

diff --git a/mm/page_cgroup.c b/mm/page_cgroup.c
index 29951abc852e..17eb5eb95bab 100644
--- a/mm/page_cgroup.c
+++ b/mm/page_cgroup.c
@@ -463,8 +463,8 @@ int swap_cgroup_swapon(int type, unsigned long max_pages)
/* memory shortage */
ctrl->map = NULL;
ctrl->length = 0;
- vfree(array);
mutex_unlock(&swap_cgroup_mutex);
+ vfree(array);
goto nomem;
}
mutex_unlock(&swap_cgroup_mutex);
@@ -479,7 +479,8 @@ nomem:

void swap_cgroup_swapoff(int type)
{
- int i;
+ struct page **map;
+ unsigned long i, length;
struct swap_cgroup_ctrl *ctrl;

if (!do_swap_account)
@@ -487,17 +488,20 @@ void swap_cgroup_swapoff(int type)

mutex_lock(&swap_cgroup_mutex);
ctrl = &swap_cgroup_ctrl[type];
- if (ctrl->map) {
- for (i = 0; i < ctrl->length; i++) {
- struct page *page = ctrl->map[i];
+ map = ctrl->map;
+ length = ctrl->length;
+ ctrl->map = NULL;
+ ctrl->length = 0;
+ mutex_unlock(&swap_cgroup_mutex);
+
+ if (map) {
+ for (i = 0; i < length; i++) {
+ struct page *page = map[i];
if (page)
__free_page(page);
}
- vfree(ctrl->map);
- ctrl->map = NULL;
- ctrl->length = 0;
+ vfree(map);
}
- mutex_unlock(&swap_cgroup_mutex);
}

#endif
--
1.7.4

2011-03-22 00:04:30

by Kamezawa Hiroyuki

[permalink] [raw]
Subject: Re: [PATCH 1/3] memcg: mark init_section_page_cgroup() properly

On Fri, 18 Mar 2011 21:54:13 +0900
Namhyung Kim <[email protected]> wrote:

> The commit ca371c0d7e23 ("memcg: fix page_cgroup fatal error
> in FLATMEM") removes call to alloc_bootmem() in the function
> so that it can be marked as __meminit to reduce memory usage
> when MEMORY_HOTPLUG=n.
>
> Signed-off-by: Namhyung Kim <[email protected]>
> Cc: KAMEZAWA Hiroyuki <[email protected]>
Acked-by: KAMEZAWA Hiroyuki <[email protected]>


> ---
> mm/page_cgroup.c | 3 +--
> 1 files changed, 1 insertions(+), 2 deletions(-)
>
> diff --git a/mm/page_cgroup.c b/mm/page_cgroup.c
> index 5bffada7cde1..2d1a0fa01d7b 100644
> --- a/mm/page_cgroup.c
> +++ b/mm/page_cgroup.c
> @@ -105,8 +105,7 @@ struct page_cgroup *lookup_page_cgroup(struct page *page)
> return section->page_cgroup + pfn;
> }
>
> -/* __alloc_bootmem...() is protected by !slab_available() */
> -static int __init_refok init_section_page_cgroup(unsigned long pfn)
> +static int __meminit init_section_page_cgroup(unsigned long pfn)
> {
> struct mem_section *section = __pfn_to_section(pfn);
> struct page_cgroup *base, *pc;
> --
> 1.7.4
>
>

2011-03-22 00:05:14

by Kamezawa Hiroyuki

[permalink] [raw]
Subject: Re: [PATCH 2/3] memcg: fix off-by-one when calculating swap cgroup map length

On Fri, 18 Mar 2011 21:54:14 +0900
Namhyung Kim <[email protected]> wrote:

> It allocated one more page than necessary if @max_pages was
> a multiple of SC_PER_PAGE.
>
> Signed-off-by: Namhyung Kim <[email protected]>
> Cc: KAMEZAWA Hiroyuki <[email protected]>

Acked-by: KAMEZAWA Hiroyuki <[email protected]>

2011-03-22 00:06:17

by Kamezawa Hiroyuki

[permalink] [raw]
Subject: Re: [PATCH 3/3] memcg: move page-freeing code outside of lock

On Fri, 18 Mar 2011 21:54:15 +0900
Namhyung Kim <[email protected]> wrote:

> Signed-off-by: Namhyung Kim <[email protected]>
> Cc: KAMEZAWA Hiroyuki <[email protected]>

What is the benefit of this patch ?

-Kame

2011-03-22 03:04:53

by Namhyung Kim

[permalink] [raw]
Subject: Re: [PATCH 3/3] memcg: move page-freeing code outside of lock

2011-03-22 (화), 08:59 +0900, KAMEZAWA Hiroyuki:
> On Fri, 18 Mar 2011 21:54:15 +0900
> Namhyung Kim <[email protected]> wrote:
>
> > Signed-off-by: Namhyung Kim <[email protected]>
> > Cc: KAMEZAWA Hiroyuki <[email protected]>
>
> What is the benefit of this patch ?
>
> -Kame
>

Oh, I just thought generally it'd better call such a (potentially)
costly function outside of locks and it could reduce few of theoretical
contentions between swapons and/or offs. If it doesn't help any
realistic cases I don't mind discarding it.

Thanks.


--
Regards,
Namhyung Kim

2011-03-22 03:09:40

by Balbir Singh

[permalink] [raw]
Subject: Re: [PATCH 3/3] memcg: move page-freeing code outside of lock

On Tue, Mar 22, 2011 at 8:34 AM, Namhyung Kim <[email protected]> wrote:
>
> 2011-03-22 (화), 08:59 +0900, KAMEZAWA Hiroyuki:
> > On Fri, 18 Mar 2011 21:54:15 +0900
> > Namhyung Kim <[email protected]> wrote:
> >
> > > Signed-off-by: Namhyung Kim <[email protected]>
> > > Cc: KAMEZAWA Hiroyuki <[email protected]>
> >
> > What is the benefit of this patch ?
> >
> > -Kame
> >
>
> Oh, I just thought generally it'd better call such a (potentially)
> costly function outside of locks and it could reduce few of theoretical
> contentions between swapons and/or offs. If it doesn't help any
> realistic cases I don't mind discarding it.

swapoff is a rare path, I would not worry about it too much at all.

Balbir

2011-03-22 03:10:55

by Balbir Singh

[permalink] [raw]
Subject: Re: [PATCH 1/3] memcg: mark init_section_page_cgroup() properly

On Tue, Mar 22, 2011 at 5:27 AM, KAMEZAWA Hiroyuki
<[email protected]> wrote:
> On Fri, 18 Mar 2011 21:54:13 +0900
> Namhyung Kim <[email protected]> wrote:
>
>> The commit ca371c0d7e23 ("memcg: fix page_cgroup fatal error
>> in FLATMEM") removes call to alloc_bootmem() in the function
>> so that it can be marked as __meminit to reduce memory usage
>> when MEMORY_HOTPLUG=n.
>>
>> Signed-off-by: Namhyung Kim <[email protected]>
>> Cc: KAMEZAWA Hiroyuki <[email protected]>
> Acked-by: KAMEZAWA Hiroyuki <[email protected]>

Acked-by: Balbir Singh <[email protected]>

2011-03-22 03:13:12

by Balbir Singh

[permalink] [raw]
Subject: Re: [PATCH 2/3] memcg: fix off-by-one when calculating swap cgroup map length

On Tue, Mar 22, 2011 at 5:28 AM, KAMEZAWA Hiroyuki
<[email protected]> wrote:
> On Fri, 18 Mar 2011 21:54:14 +0900
> Namhyung Kim <[email protected]> wrote:
>
>> It allocated one more page than necessary if @max_pages was
>> a multiple of SC_PER_PAGE.
>>
>> Signed-off-by: Namhyung Kim <[email protected]>
>> Cc: KAMEZAWA Hiroyuki <[email protected]>
>
> Acked-by: KAMEZAWA Hiroyuki <[email protected]>

Acked-by: Balbir Singh <[email protected]>

2011-03-22 05:02:58

by Kamezawa Hiroyuki

[permalink] [raw]
Subject: Re: [PATCH 3/3] memcg: move page-freeing code outside of lock

On Tue, 22 Mar 2011 12:04:39 +0900
Namhyung Kim <[email protected]> wrote:

> 2011-03-22 (화), 08:59 +0900, KAMEZAWA Hiroyuki:
> > On Fri, 18 Mar 2011 21:54:15 +0900
> > Namhyung Kim <[email protected]> wrote:
> >
> > > Signed-off-by: Namhyung Kim <[email protected]>
> > > Cc: KAMEZAWA Hiroyuki <[email protected]>
> >
> > What is the benefit of this patch ?
> >
> > -Kame
> >
>
> Oh, I just thought generally it'd better call such a (potentially)
> costly function outside of locks and it could reduce few of theoretical
> contentions between swapons and/or offs. If it doesn't help any
> realistic cases I don't mind discarding it.
>

My point is, please write patch description which shows for what this patc is.
All cleanup are okay to me if it reasonable. But without patch description as
"this is just a cleanup, no functional change, and the reason is...."
we cannot maintain patches.

Thanks,
-Kame

2011-03-22 10:07:07

by Namhyung Kim

[permalink] [raw]
Subject: Re: [PATCH 3/3] memcg: move page-freeing code outside of lock

2011-03-22 (화), 13:56 +0900, KAMEZAWA Hiroyuki:
> On Tue, 22 Mar 2011 12:04:39 +0900
> Namhyung Kim <[email protected]> wrote:
>
> > 2011-03-22 (화), 08:59 +0900, KAMEZAWA Hiroyuki:
> > > On Fri, 18 Mar 2011 21:54:15 +0900
> > > Namhyung Kim <[email protected]> wrote:
> > >
> > > > Signed-off-by: Namhyung Kim <[email protected]>
> > > > Cc: KAMEZAWA Hiroyuki <[email protected]>
> > >
> > > What is the benefit of this patch ?
> > >
> > > -Kame
> > >
> >
> > Oh, I just thought generally it'd better call such a (potentially)
> > costly function outside of locks and it could reduce few of theoretical
> > contentions between swapons and/or offs. If it doesn't help any
> > realistic cases I don't mind discarding it.
> >
>
> My point is, please write patch description which shows for what this patc is.
> All cleanup are okay to me if it reasonable. But without patch description as
> "this is just a cleanup, no functional change, and the reason is...."
> we cannot maintain patches.
>
> Thanks,
> -Kame
>

OK, I will do that in the future. Anyway, do you want me to resend the
patch with new description?

Thanks.


--
Regards,
Namhyung Kim

2011-03-23 04:42:44

by Kamezawa Hiroyuki

[permalink] [raw]
Subject: Re: [PATCH 3/3] memcg: move page-freeing code outside of lock

On Tue, 22 Mar 2011 19:06:57 +0900
Namhyung Kim <[email protected]> wrote:

> 2011-03-22 (화), 13:56 +0900, KAMEZAWA Hiroyuki:
> > On Tue, 22 Mar 2011 12:04:39 +0900
> > Namhyung Kim <[email protected]> wrote:
> >
> > > 2011-03-22 (화), 08:59 +0900, KAMEZAWA Hiroyuki:
> > > > On Fri, 18 Mar 2011 21:54:15 +0900
> > > > Namhyung Kim <[email protected]> wrote:
> > > >
> > > > > Signed-off-by: Namhyung Kim <[email protected]>
> > > > > Cc: KAMEZAWA Hiroyuki <[email protected]>
> > > >
> > > > What is the benefit of this patch ?
> > > >
> > > > -Kame
> > > >
> > >
> > > Oh, I just thought generally it'd better call such a (potentially)
> > > costly function outside of locks and it could reduce few of theoretical
> > > contentions between swapons and/or offs. If it doesn't help any
> > > realistic cases I don't mind discarding it.
> > >
> >
> > My point is, please write patch description which shows for what this patc is.
> > All cleanup are okay to me if it reasonable. But without patch description as
> > "this is just a cleanup, no functional change, and the reason is...."
> > we cannot maintain patches.
> >
> > Thanks,
> > -Kame
> >
>
> OK, I will do that in the future. Anyway, do you want me to resend the
> patch with new description?
>

please. I'll never ack a patch without description.

Thanks,
-Kame

2011-03-23 11:59:33

by Namhyung Kim

[permalink] [raw]
Subject: [PATCH] memcg: move page-freeing code out of lock

Move page-freeing code out of swap_cgroup_mutex in the hope that it
could reduce few of theoretical contentions between swapons and/or
swapoffs.

This is just a cleanup, no functional changes.

Signed-off-by: Namhyung Kim <[email protected]>
Cc: Paul Menage <[email protected]>
Cc: Li Zefan <[email protected]>
Cc: [email protected]
---
mm/page_cgroup.c | 22 +++++++++++++---------
1 files changed, 13 insertions(+), 9 deletions(-)

diff --git a/mm/page_cgroup.c b/mm/page_cgroup.c
index 29951abc852e..17eb5eb95bab 100644
--- a/mm/page_cgroup.c
+++ b/mm/page_cgroup.c
@@ -463,8 +463,8 @@ int swap_cgroup_swapon(int type, unsigned long max_pages)
/* memory shortage */
ctrl->map = NULL;
ctrl->length = 0;
- vfree(array);
mutex_unlock(&swap_cgroup_mutex);
+ vfree(array);
goto nomem;
}
mutex_unlock(&swap_cgroup_mutex);
@@ -479,7 +479,8 @@ nomem:

void swap_cgroup_swapoff(int type)
{
- int i;
+ struct page **map;
+ unsigned long i, length;
struct swap_cgroup_ctrl *ctrl;

if (!do_swap_account)
@@ -487,17 +488,20 @@ void swap_cgroup_swapoff(int type)

mutex_lock(&swap_cgroup_mutex);
ctrl = &swap_cgroup_ctrl[type];
- if (ctrl->map) {
- for (i = 0; i < ctrl->length; i++) {
- struct page *page = ctrl->map[i];
+ map = ctrl->map;
+ length = ctrl->length;
+ ctrl->map = NULL;
+ ctrl->length = 0;
+ mutex_unlock(&swap_cgroup_mutex);
+
+ if (map) {
+ for (i = 0; i < length; i++) {
+ struct page *page = map[i];
if (page)
__free_page(page);
}
- vfree(ctrl->map);
- ctrl->map = NULL;
- ctrl->length = 0;
+ vfree(map);
}
- mutex_unlock(&swap_cgroup_mutex);
}

#endif
--
1.7.4

2011-03-23 23:44:09

by Kamezawa Hiroyuki

[permalink] [raw]
Subject: Re: [PATCH] memcg: move page-freeing code out of lock

On Wed, 23 Mar 2011 20:59:18 +0900
Namhyung Kim <[email protected]> wrote:

> Move page-freeing code out of swap_cgroup_mutex in the hope that it
> could reduce few of theoretical contentions between swapons and/or
> swapoffs.
>
> This is just a cleanup, no functional changes.
>
> Signed-off-by: Namhyung Kim <[email protected]>
> Cc: Paul Menage <[email protected]>
> Cc: Li Zefan <[email protected]>
> Cc: [email protected]

Acked-by: KAMEZAWA Hiroyuki <[email protected]>

2011-04-01 01:19:12

by Namhyung Kim

[permalink] [raw]
Subject: Re: [PATCH 1/3] memcg: mark init_section_page_cgroup() properly

2011-03-18 (금), 21:54 +0900, Namhyung Kim:
> The commit ca371c0d7e23 ("memcg: fix page_cgroup fatal error
> in FLATMEM") removes call to alloc_bootmem() in the function
> so that it can be marked as __meminit to reduce memory usage
> when MEMORY_HOTPLUG=n.
>
> Signed-off-by: Namhyung Kim <[email protected]>
> Cc: KAMEZAWA Hiroyuki <[email protected]>
> ---
> mm/page_cgroup.c | 3 +--
> 1 files changed, 1 insertions(+), 2 deletions(-)
>
> diff --git a/mm/page_cgroup.c b/mm/page_cgroup.c
> index 5bffada7cde1..2d1a0fa01d7b 100644
> --- a/mm/page_cgroup.c
> +++ b/mm/page_cgroup.c
> @@ -105,8 +105,7 @@ struct page_cgroup *lookup_page_cgroup(struct page *page)
> return section->page_cgroup + pfn;
> }
>
> -/* __alloc_bootmem...() is protected by !slab_available() */
> -static int __init_refok init_section_page_cgroup(unsigned long pfn)
> +static int __meminit init_section_page_cgroup(unsigned long pfn)
> {
> struct mem_section *section = __pfn_to_section(pfn);
> struct page_cgroup *base, *pc;

Andrew, could you please have a look these patches too and consider
applying them in your tree? I can resend them (with given Acked-by
lines) if you want.

Thanks.


--
Regards,
Namhyung Kim