All of lore.kernel.org
 help / color / mirror / Atom feed
From: Vladimir Davydov <vdavydov@parallels.com>
To: Greg Thelen <gthelen@google.com>
Cc: akpm@linux-foundation.org, hannes@cmpxchg.org, mhocko@suse.cz,
	glommer@gmail.com, linux-kernel@vger.kernel.org,
	linux-mm@kvack.org, devel@openvz.org
Subject: Re: [PATCH -mm v2.1] mm: get rid of __GFP_KMEMCG
Date: Thu, 3 Apr 2014 19:04:04 +0400	[thread overview]
Message-ID: <533D7864.7080907@parallels.com> (raw)
In-Reply-To: <xr934n2bjuec.fsf@gthelen.mtv.corp.google.com>

On 04/03/2014 01:25 AM, Greg Thelen wrote:
> On Tue, Apr 01 2014, Vladimir Davydov <vdavydov@parallels.com> wrote:
>
>> Currently to allocate a page that should be charged to kmemcg (e.g.
>> threadinfo), we pass __GFP_KMEMCG flag to the page allocator. The page
>> allocated is then to be freed by free_memcg_kmem_pages. Apart from
>> looking asymmetrical, this also requires intrusion to the general
>> allocation path. So let's introduce separate functions that will
>> alloc/free pages charged to kmemcg.
>>
>> The new functions are called alloc_kmem_pages and free_kmem_pages. They
>> should be used when the caller actually would like to use kmalloc, but
>> has to fall back to the page allocator for the allocation is large. They
>> only differ from alloc_pages and free_pages in that besides allocating
>> or freeing pages they also charge them to the kmem resource counter of
>> the current memory cgroup.
>>
>> Signed-off-by: Vladimir Davydov <vdavydov@parallels.com>
> One comment nit below, otherwise looks good to me.
>
> Acked-by: Greg Thelen <gthelen@google.com>
>
>> Cc: Johannes Weiner <hannes@cmpxchg.org>
>> Cc: Michal Hocko <mhocko@suse.cz>
>> Cc: Glauber Costa <glommer@gmail.com>
>> Cc: Christoph Lameter <cl@linux-foundation.org>
>> Cc: Pekka Enberg <penberg@kernel.org>
>> ---
>> Changes in v2.1:
>>  - add missing kmalloc_order forward declaration; lacking it caused
>>    compilation breakage with CONFIG_TRACING=n
>>
>>  include/linux/gfp.h             |   10 ++++---
>>  include/linux/memcontrol.h      |    2 +-
>>  include/linux/slab.h            |   11 +-------
>>  include/linux/thread_info.h     |    2 --
>>  include/trace/events/gfpflags.h |    1 -
>>  kernel/fork.c                   |    6 ++---
>>  mm/page_alloc.c                 |   56 ++++++++++++++++++++++++---------------
>>  mm/slab_common.c                |   12 +++++++++
>>  mm/slub.c                       |    6 ++---
>>  9 files changed, 61 insertions(+), 45 deletions(-)
>>
>> diff --git a/include/linux/gfp.h b/include/linux/gfp.h
>> index 39b81dc7d01a..d382db71e300 100644
>> --- a/include/linux/gfp.h
>> +++ b/include/linux/gfp.h
>> @@ -31,7 +31,6 @@ struct vm_area_struct;
>>  #define ___GFP_HARDWALL		0x20000u
>>  #define ___GFP_THISNODE		0x40000u
>>  #define ___GFP_RECLAIMABLE	0x80000u
>> -#define ___GFP_KMEMCG		0x100000u
>>  #define ___GFP_NOTRACK		0x200000u
>>  #define ___GFP_NO_KSWAPD	0x400000u
>>  #define ___GFP_OTHER_NODE	0x800000u
>> @@ -91,7 +90,6 @@ struct vm_area_struct;
>>  
>>  #define __GFP_NO_KSWAPD	((__force gfp_t)___GFP_NO_KSWAPD)
>>  #define __GFP_OTHER_NODE ((__force gfp_t)___GFP_OTHER_NODE) /* On behalf of other node */
>> -#define __GFP_KMEMCG	((__force gfp_t)___GFP_KMEMCG) /* Allocation comes from a memcg-accounted resource */
>>  #define __GFP_WRITE	((__force gfp_t)___GFP_WRITE)	/* Allocator intends to dirty page */
>>  
>>  /*
>> @@ -353,6 +351,10 @@ extern struct page *alloc_pages_vma(gfp_t gfp_mask, int order,
>>  #define alloc_page_vma_node(gfp_mask, vma, addr, node)		\
>>  	alloc_pages_vma(gfp_mask, 0, vma, addr, node)
>>  
>> +extern struct page *alloc_kmem_pages(gfp_t gfp_mask, unsigned int order);
>> +extern struct page *alloc_kmem_pages_node(int nid, gfp_t gfp_mask,
>> +					  unsigned int order);
>> +
>>  extern unsigned long __get_free_pages(gfp_t gfp_mask, unsigned int order);
>>  extern unsigned long get_zeroed_page(gfp_t gfp_mask);
>>  
>> @@ -372,8 +374,8 @@ extern void free_pages(unsigned long addr, unsigned int order);
>>  extern void free_hot_cold_page(struct page *page, int cold);
>>  extern void free_hot_cold_page_list(struct list_head *list, int cold);
>>  
>> -extern void __free_memcg_kmem_pages(struct page *page, unsigned int order);
>> -extern void free_memcg_kmem_pages(unsigned long addr, unsigned int order);
>> +extern void __free_kmem_pages(struct page *page, unsigned int order);
>> +extern void free_kmem_pages(unsigned long addr, unsigned int order);
>>  
>>  #define __free_page(page) __free_pages((page), 0)
>>  #define free_page(addr) free_pages((addr), 0)
>> diff --git a/include/linux/memcontrol.h b/include/linux/memcontrol.h
>> index 29068dd26c3d..13acdb5259f5 100644
>> --- a/include/linux/memcontrol.h
>> +++ b/include/linux/memcontrol.h
>> @@ -543,7 +543,7 @@ memcg_kmem_newpage_charge(gfp_t gfp, struct mem_cgroup **memcg, int order)
>>  	 * res_counter_charge_nofail, but we hope those allocations are rare,
>>  	 * and won't be worth the trouble.
>>  	 */
> Just a few lines higher in first memcg_kmem_newpage_charge() comment,
> there is a leftover reference to GFP_KMEMCG which should be removed.

Good catch, will resend.

Thank you for the review!

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

WARNING: multiple messages have this Message-ID (diff)
From: Vladimir Davydov <vdavydov@parallels.com>
To: Greg Thelen <gthelen@google.com>
Cc: <akpm@linux-foundation.org>, <hannes@cmpxchg.org>,
	<mhocko@suse.cz>, <glommer@gmail.com>,
	<linux-kernel@vger.kernel.org>, <linux-mm@kvack.org>,
	<devel@openvz.org>
Subject: Re: [PATCH -mm v2.1] mm: get rid of __GFP_KMEMCG
Date: Thu, 3 Apr 2014 19:04:04 +0400	[thread overview]
Message-ID: <533D7864.7080907@parallels.com> (raw)
In-Reply-To: <xr934n2bjuec.fsf@gthelen.mtv.corp.google.com>

On 04/03/2014 01:25 AM, Greg Thelen wrote:
> On Tue, Apr 01 2014, Vladimir Davydov <vdavydov@parallels.com> wrote:
>
>> Currently to allocate a page that should be charged to kmemcg (e.g.
>> threadinfo), we pass __GFP_KMEMCG flag to the page allocator. The page
>> allocated is then to be freed by free_memcg_kmem_pages. Apart from
>> looking asymmetrical, this also requires intrusion to the general
>> allocation path. So let's introduce separate functions that will
>> alloc/free pages charged to kmemcg.
>>
>> The new functions are called alloc_kmem_pages and free_kmem_pages. They
>> should be used when the caller actually would like to use kmalloc, but
>> has to fall back to the page allocator for the allocation is large. They
>> only differ from alloc_pages and free_pages in that besides allocating
>> or freeing pages they also charge them to the kmem resource counter of
>> the current memory cgroup.
>>
>> Signed-off-by: Vladimir Davydov <vdavydov@parallels.com>
> One comment nit below, otherwise looks good to me.
>
> Acked-by: Greg Thelen <gthelen@google.com>
>
>> Cc: Johannes Weiner <hannes@cmpxchg.org>
>> Cc: Michal Hocko <mhocko@suse.cz>
>> Cc: Glauber Costa <glommer@gmail.com>
>> Cc: Christoph Lameter <cl@linux-foundation.org>
>> Cc: Pekka Enberg <penberg@kernel.org>
>> ---
>> Changes in v2.1:
>>  - add missing kmalloc_order forward declaration; lacking it caused
>>    compilation breakage with CONFIG_TRACING=n
>>
>>  include/linux/gfp.h             |   10 ++++---
>>  include/linux/memcontrol.h      |    2 +-
>>  include/linux/slab.h            |   11 +-------
>>  include/linux/thread_info.h     |    2 --
>>  include/trace/events/gfpflags.h |    1 -
>>  kernel/fork.c                   |    6 ++---
>>  mm/page_alloc.c                 |   56 ++++++++++++++++++++++++---------------
>>  mm/slab_common.c                |   12 +++++++++
>>  mm/slub.c                       |    6 ++---
>>  9 files changed, 61 insertions(+), 45 deletions(-)
>>
>> diff --git a/include/linux/gfp.h b/include/linux/gfp.h
>> index 39b81dc7d01a..d382db71e300 100644
>> --- a/include/linux/gfp.h
>> +++ b/include/linux/gfp.h
>> @@ -31,7 +31,6 @@ struct vm_area_struct;
>>  #define ___GFP_HARDWALL		0x20000u
>>  #define ___GFP_THISNODE		0x40000u
>>  #define ___GFP_RECLAIMABLE	0x80000u
>> -#define ___GFP_KMEMCG		0x100000u
>>  #define ___GFP_NOTRACK		0x200000u
>>  #define ___GFP_NO_KSWAPD	0x400000u
>>  #define ___GFP_OTHER_NODE	0x800000u
>> @@ -91,7 +90,6 @@ struct vm_area_struct;
>>  
>>  #define __GFP_NO_KSWAPD	((__force gfp_t)___GFP_NO_KSWAPD)
>>  #define __GFP_OTHER_NODE ((__force gfp_t)___GFP_OTHER_NODE) /* On behalf of other node */
>> -#define __GFP_KMEMCG	((__force gfp_t)___GFP_KMEMCG) /* Allocation comes from a memcg-accounted resource */
>>  #define __GFP_WRITE	((__force gfp_t)___GFP_WRITE)	/* Allocator intends to dirty page */
>>  
>>  /*
>> @@ -353,6 +351,10 @@ extern struct page *alloc_pages_vma(gfp_t gfp_mask, int order,
>>  #define alloc_page_vma_node(gfp_mask, vma, addr, node)		\
>>  	alloc_pages_vma(gfp_mask, 0, vma, addr, node)
>>  
>> +extern struct page *alloc_kmem_pages(gfp_t gfp_mask, unsigned int order);
>> +extern struct page *alloc_kmem_pages_node(int nid, gfp_t gfp_mask,
>> +					  unsigned int order);
>> +
>>  extern unsigned long __get_free_pages(gfp_t gfp_mask, unsigned int order);
>>  extern unsigned long get_zeroed_page(gfp_t gfp_mask);
>>  
>> @@ -372,8 +374,8 @@ extern void free_pages(unsigned long addr, unsigned int order);
>>  extern void free_hot_cold_page(struct page *page, int cold);
>>  extern void free_hot_cold_page_list(struct list_head *list, int cold);
>>  
>> -extern void __free_memcg_kmem_pages(struct page *page, unsigned int order);
>> -extern void free_memcg_kmem_pages(unsigned long addr, unsigned int order);
>> +extern void __free_kmem_pages(struct page *page, unsigned int order);
>> +extern void free_kmem_pages(unsigned long addr, unsigned int order);
>>  
>>  #define __free_page(page) __free_pages((page), 0)
>>  #define free_page(addr) free_pages((addr), 0)
>> diff --git a/include/linux/memcontrol.h b/include/linux/memcontrol.h
>> index 29068dd26c3d..13acdb5259f5 100644
>> --- a/include/linux/memcontrol.h
>> +++ b/include/linux/memcontrol.h
>> @@ -543,7 +543,7 @@ memcg_kmem_newpage_charge(gfp_t gfp, struct mem_cgroup **memcg, int order)
>>  	 * res_counter_charge_nofail, but we hope those allocations are rare,
>>  	 * and won't be worth the trouble.
>>  	 */
> Just a few lines higher in first memcg_kmem_newpage_charge() comment,
> there is a leftover reference to GFP_KMEMCG which should be removed.

Good catch, will resend.

Thank you for the review!

  reply	other threads:[~2014-04-03 15:04 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-04-01  7:38 [PATCH -mm v2 0/2] cleanup kmemcg charging (was: "kmemcg: get rid of __GFP_KMEMCG") Vladimir Davydov
2014-04-01  7:38 ` Vladimir Davydov
2014-04-01  7:38 ` [PATCH -mm v2 1/2] sl[au]b: charge slabs to kmemcg explicitly Vladimir Davydov
2014-04-01  7:38   ` Vladimir Davydov
2014-04-02  0:49   ` Greg Thelen
2014-04-02  0:49     ` Greg Thelen
2014-04-01  7:38 ` [PATCH -mm v2 2/2] mm: get rid of __GFP_KMEMCG Vladimir Davydov
2014-04-01  7:38   ` Vladimir Davydov
2014-04-02  0:48   ` Greg Thelen
2014-04-02  0:48     ` Greg Thelen
2014-04-02  6:11     ` Vladimir Davydov
2014-04-02  6:11       ` Vladimir Davydov
2014-04-02  6:16   ` [PATCH -mm v2.1] " Vladimir Davydov
2014-04-02  6:16     ` Vladimir Davydov
2014-04-02 21:25     ` Greg Thelen
2014-04-02 21:25       ` Greg Thelen
2014-04-03 15:04       ` Vladimir Davydov [this message]
2014-04-03 15:04         ` Vladimir Davydov
2014-04-03 15:05     ` [PATCH -mm v2.2] " Vladimir Davydov
2014-04-03 15:05       ` Vladimir Davydov
2014-04-10 23:38       ` Andrew Morton
2014-04-10 23:38         ` Andrew Morton
2014-04-11 12:52         ` [PATCH -mm] slab: document kmalloc_order Vladimir Davydov
2014-04-11 12:52           ` Vladimir Davydov
2014-04-11 15:57           ` Christoph Lameter
2014-04-11 15:57             ` Christoph Lameter
2014-04-11 17:24             ` Vladimir Davydov
2014-04-11 17:24               ` Vladimir Davydov
2014-04-11 16:07       ` [PATCH -mm v2.2] mm: get rid of __GFP_KMEMCG Christoph Lameter
2014-04-11 16:07         ` Christoph Lameter
2014-04-11 17:33         ` Vladimir Davydov
2014-04-11 17:33           ` Vladimir Davydov

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=533D7864.7080907@parallels.com \
    --to=vdavydov@parallels.com \
    --cc=akpm@linux-foundation.org \
    --cc=devel@openvz.org \
    --cc=glommer@gmail.com \
    --cc=gthelen@google.com \
    --cc=hannes@cmpxchg.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=mhocko@suse.cz \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.