All of lore.kernel.org
 help / color / mirror / Atom feed
From: Konstantin Khlebnikov <khlebnikov@parallels.com>
To: Eric Dumazet <eric.dumazet@gmail.com>
Cc: Christoph Lameter <cl@linux.com>, Mel Gorman <mgorman@suse.de>,
	Pekka Enberg <penberg@kernel.org>,
	Andrew Morton <akpm@linux-foundation.org>,
	"linux-mm@kvack.org" <linux-mm@kvack.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Matt Mackall <mpm@selenic.com>
Subject: Re: [PATCH] mm-slab: allocate kmem_cache with __GFP_REPEAT
Date: Sun, 31 Jul 2011 15:41:31 +0400	[thread overview]
Message-ID: <4E353F6B.1030501@parallels.com> (raw)
In-Reply-To: <1311174562.2338.42.camel@edumazet-HP-Compaq-6005-Pro-SFF-PC>

It seems someone forgot this patch,
the second one "slab: shrink sizeof(struct kmem_cache)" already in mainline

Eric Dumazet wrote:
> Le mercredi 20 juillet 2011 à 09:52 -0500, Christoph Lameter a écrit :
>> On Wed, 20 Jul 2011, Eric Dumazet wrote:
>>
>>>> Slab's kmem_cache is configured with an array of NR_CPUS which is the
>>>> maximum nr of cpus supported. Some distros support 4096 cpus in order to
>>>> accomodate SGI machines. That array then will have the size of 4096 * 8 =
>>>> 32k
>>>
>>> We currently support a dynamic schem for the possible nodes :
>>>
>>> cache_cache.buffer_size = offsetof(struct kmem_cache, nodelists) +
>>> 	nr_node_ids * sizeof(struct kmem_list3 *);
>>>
>>> We could have a similar trick to make the real size both depends on
>>> nr_node_ids and nr_cpu_ids.
>>>
>>> (struct kmem_cache)->array would become a pointer.
>>
>> We should be making it a per cpu pointer like slub then. I looked at what
>> it would take to do so a couple of month ago but it was quite invasive.
>>
>
> Lets try this first patch, simple enough : No need to setup percpu data
> for a one time use structure...
>
> [PATCH] slab: remove one NR_CPUS dependency
>
> Reduce high order allocations in do_tune_cpucache() for some setups.
> (NR_CPUS=4096 ->  we need 64KB)
>
> Signed-off-by: Eric Dumazet<eric.dumazet@gmail.com>
> CC: Pekka Enberg<penberg@kernel.org>
> CC: Christoph Lameter<cl@linux.com>
> ---
>   mm/slab.c |    5 +++--
>   1 file changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/mm/slab.c b/mm/slab.c
> index d96e223..862bd12 100644
> --- a/mm/slab.c
> +++ b/mm/slab.c
> @@ -3933,7 +3933,7 @@ fail:
>
>   struct ccupdate_struct {
>   	struct kmem_cache *cachep;
> -	struct array_cache *new[NR_CPUS];
> +	struct array_cache *new[0];
>   };
>
>   static void do_ccupdate_local(void *info)
> @@ -3955,7 +3955,8 @@ static int do_tune_cpucache(struct kmem_cache *cachep, int limit,
>   	struct ccupdate_struct *new;
>   	int i;
>
> -	new = kzalloc(sizeof(*new), gfp);
> +	new = kzalloc(sizeof(*new) + nr_cpu_ids * sizeof(struct array_cache *),
> +		      gfp);
>   	if (!new)
>   		return -ENOMEM;
>
>
>


WARNING: multiple messages have this Message-ID (diff)
From: Konstantin Khlebnikov <khlebnikov@parallels.com>
To: Eric Dumazet <eric.dumazet@gmail.com>
Cc: Christoph Lameter <cl@linux.com>, Mel Gorman <mgorman@suse.de>,
	Pekka Enberg <penberg@kernel.org>,
	Andrew Morton <akpm@linux-foundation.org>,
	"linux-mm@kvack.org" <linux-mm@kvack.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Matt Mackall <mpm@selenic.com>
Subject: Re: [PATCH] mm-slab: allocate kmem_cache with __GFP_REPEAT
Date: Sun, 31 Jul 2011 15:41:31 +0400	[thread overview]
Message-ID: <4E353F6B.1030501@parallels.com> (raw)
In-Reply-To: <1311174562.2338.42.camel@edumazet-HP-Compaq-6005-Pro-SFF-PC>

It seems someone forgot this patch,
the second one "slab: shrink sizeof(struct kmem_cache)" already in mainline

Eric Dumazet wrote:
> Le mercredi 20 juillet 2011 à 09:52 -0500, Christoph Lameter a écrit :
>> On Wed, 20 Jul 2011, Eric Dumazet wrote:
>>
>>>> Slab's kmem_cache is configured with an array of NR_CPUS which is the
>>>> maximum nr of cpus supported. Some distros support 4096 cpus in order to
>>>> accomodate SGI machines. That array then will have the size of 4096 * 8 =
>>>> 32k
>>>
>>> We currently support a dynamic schem for the possible nodes :
>>>
>>> cache_cache.buffer_size = offsetof(struct kmem_cache, nodelists) +
>>> 	nr_node_ids * sizeof(struct kmem_list3 *);
>>>
>>> We could have a similar trick to make the real size both depends on
>>> nr_node_ids and nr_cpu_ids.
>>>
>>> (struct kmem_cache)->array would become a pointer.
>>
>> We should be making it a per cpu pointer like slub then. I looked at what
>> it would take to do so a couple of month ago but it was quite invasive.
>>
>
> Lets try this first patch, simple enough : No need to setup percpu data
> for a one time use structure...
>
> [PATCH] slab: remove one NR_CPUS dependency
>
> Reduce high order allocations in do_tune_cpucache() for some setups.
> (NR_CPUS=4096 ->  we need 64KB)
>
> Signed-off-by: Eric Dumazet<eric.dumazet@gmail.com>
> CC: Pekka Enberg<penberg@kernel.org>
> CC: Christoph Lameter<cl@linux.com>
> ---
>   mm/slab.c |    5 +++--
>   1 file changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/mm/slab.c b/mm/slab.c
> index d96e223..862bd12 100644
> --- a/mm/slab.c
> +++ b/mm/slab.c
> @@ -3933,7 +3933,7 @@ fail:
>
>   struct ccupdate_struct {
>   	struct kmem_cache *cachep;
> -	struct array_cache *new[NR_CPUS];
> +	struct array_cache *new[0];
>   };
>
>   static void do_ccupdate_local(void *info)
> @@ -3955,7 +3955,8 @@ static int do_tune_cpucache(struct kmem_cache *cachep, int limit,
>   	struct ccupdate_struct *new;
>   	int i;
>
> -	new = kzalloc(sizeof(*new), gfp);
> +	new = kzalloc(sizeof(*new) + nr_cpu_ids * sizeof(struct array_cache *),
> +		      gfp);
>   	if (!new)
>   		return -ENOMEM;
>
>
>

--
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/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

  parent reply	other threads:[~2011-07-31 11:41 UTC|newest]

Thread overview: 67+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-07-20 12:16 [PATCH] mm-slab: allocate kmem_cache with __GFP_REPEAT Konstantin Khlebnikov
2011-07-20 12:16 ` Konstantin Khlebnikov
2011-07-20 13:14 ` Pekka Enberg
2011-07-20 13:14   ` Pekka Enberg
2011-07-20 13:28   ` Konstantin Khlebnikov
2011-07-20 13:28     ` Konstantin Khlebnikov
2011-07-20 13:42     ` Pekka Enberg
2011-07-20 13:42       ` Pekka Enberg
2011-07-20 13:50       ` Konstantin Khlebnikov
2011-07-20 13:50         ` Konstantin Khlebnikov
2011-07-20 13:53         ` Pekka Enberg
2011-07-20 13:53           ` Pekka Enberg
2011-07-20 15:36           ` Christoph Lameter
2011-07-20 15:36             ` Christoph Lameter
2011-07-20 13:59         ` Konstantin Khlebnikov
2011-07-20 13:59           ` Konstantin Khlebnikov
2011-07-20 13:54       ` Christoph Lameter
2011-07-20 13:54         ` Christoph Lameter
2011-07-20 14:20         ` Mel Gorman
2011-07-20 14:20           ` Mel Gorman
2011-07-20 14:32           ` Konstantin Khlebnikov
2011-07-20 14:32             ` Konstantin Khlebnikov
2011-07-20 14:40             ` Eric Dumazet
2011-07-20 14:40               ` Eric Dumazet
2011-07-20 14:47               ` Konstantin Khlebnikov
2011-07-20 14:47                 ` Konstantin Khlebnikov
2011-07-20 13:43   ` Mel Gorman
2011-07-20 13:43     ` Mel Gorman
2011-07-20 13:56     ` Christoph Lameter
2011-07-20 13:56       ` Christoph Lameter
2011-07-20 14:08       ` Eric Dumazet
2011-07-20 14:08         ` Eric Dumazet
2011-07-20 14:52         ` Christoph Lameter
2011-07-20 14:52           ` Christoph Lameter
2011-07-20 15:09           ` Eric Dumazet
2011-07-20 15:09             ` Eric Dumazet
2011-07-20 15:34             ` Christoph Lameter
2011-07-20 15:34               ` Christoph Lameter
2011-07-20 15:56               ` Eric Dumazet
2011-07-20 15:56                 ` Eric Dumazet
2011-07-20 16:17                 ` Christoph Lameter
2011-07-20 16:17                   ` Christoph Lameter
2011-07-20 16:31                   ` Eric Dumazet
2011-07-20 16:31                     ` Eric Dumazet
2011-07-20 17:04                     ` Eric Dumazet
2011-07-20 17:04                       ` Eric Dumazet
2011-07-20 17:13                       ` Christoph Lameter
2011-07-20 17:13                         ` Christoph Lameter
2011-07-20 17:28                         ` Pekka Enberg
2011-07-20 17:28                           ` Pekka Enberg
2011-07-20 17:37                           ` Christoph Lameter
2011-07-20 17:37                             ` Christoph Lameter
2011-07-20 17:41                             ` Pekka Enberg
2011-07-20 17:41                               ` Pekka Enberg
2011-07-20 18:07                               ` Matt Mackall
2011-07-20 18:07                                 ` Matt Mackall
2011-07-21  7:18                                 ` Konstantin Khlebnikov
2011-07-21  7:18                                   ` Konstantin Khlebnikov
2011-07-20 19:09                               ` Mel Gorman
2011-07-20 19:09                                 ` Mel Gorman
2011-07-31 11:41             ` Konstantin Khlebnikov [this message]
2011-07-31 11:41               ` Konstantin Khlebnikov
2011-07-31 11:44               ` Pekka Enberg
2011-07-31 11:44                 ` Pekka Enberg
2011-07-21  8:43           ` Eric Dumazet
2011-07-21  8:43             ` Eric Dumazet
2011-07-21 15:27             ` Christoph Lameter

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=4E353F6B.1030501@parallels.com \
    --to=khlebnikov@parallels.com \
    --cc=akpm@linux-foundation.org \
    --cc=cl@linux.com \
    --cc=eric.dumazet@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=mgorman@suse.de \
    --cc=mpm@selenic.com \
    --cc=penberg@kernel.org \
    /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.