All of lore.kernel.org
 help / color / mirror / Atom feed
From: Glauber Costa <glommer@parallels.com>
To: Dave Chinner <david@fromorbit.com>
Cc: <linux-kernel@vger.kernel.org>, <linux-fsdevel@vger.kernel.org>,
	<linux-mm@kvack.org>, <xfs@oss.sgi.com>,
	Greg Thelen <gthelen@google.com>, Ying Han <yinghan@google.com>,
	Suleiman Souhlal <suleiman@google.com>
Subject: Re: [PATCH 09/19] list_lru: per-node list infrastructure
Date: Wed, 16 Jan 2013 11:21:44 -0800	[thread overview]
Message-ID: <50F6FDC8.5020909@parallels.com> (raw)
In-Reply-To: <1354058086-27937-10-git-send-email-david@fromorbit.com>

On 11/27/2012 03:14 PM, Dave Chinner wrote:
> From: Dave Chinner <dchinner@redhat.com>
> 
> Now that we have an LRU list API, we can start to enhance the
> implementation.  This splits the single LRU list into per-node lists
> and locks to enhance scalability. Items are placed on lists
> according to the node the memory belongs to. To make scanning the
> lists efficient, also track whether the per-node lists have entries
> in them in a active nodemask.
> 
> Signed-off-by: Dave Chinner <dchinner@redhat.com>
> ---
>  include/linux/list_lru.h |   14 ++--
>  lib/list_lru.c           |  160 +++++++++++++++++++++++++++++++++++-----------
>  2 files changed, 129 insertions(+), 45 deletions(-)
> 
> diff --git a/include/linux/list_lru.h b/include/linux/list_lru.h
> index 3423949..b0e3ba2 100644
> --- a/include/linux/list_lru.h
> +++ b/include/linux/list_lru.h
> @@ -8,21 +8,23 @@
>  #define _LRU_LIST_H 0
>  
>  #include <linux/list.h>
> +#include <linux/nodemask.h>
>  
> -struct list_lru {
> +struct list_lru_node {
>  	spinlock_t		lock;
>  	struct list_head	list;
>  	long			nr_items;
> +} ____cacheline_aligned_in_smp;
> +
> +struct list_lru {
> +	struct list_lru_node	node[MAX_NUMNODES];
> +	nodemask_t		active_nodes;
>  };
>  
MAX_NUMNODES will default to 1 << 9, if I'm not mistaken. Your
list_lru_node seems to be around 32 bytes on 64-bit systems (128 with
debug). So we're talking about 16k per lru.
The superblocks only, are present by the dozens even in a small system,
and I believe the whole goal of this API is to get more users to switch
to it. This can easily use up a respectable bunch of megs.

Isn't it a bit too much ?

I am wondering if we can't do better in here and at least allocate+grow
according to the actual number of nodes.

--
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: Glauber Costa <glommer@parallels.com>
To: Dave Chinner <david@fromorbit.com>
Cc: linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org,
	linux-mm@kvack.org, xfs@oss.sgi.com,
	Greg Thelen <gthelen@google.com>, Ying Han <yinghan@google.com>,
	Suleiman Souhlal <suleiman@google.com>
Subject: Re: [PATCH 09/19] list_lru: per-node list infrastructure
Date: Wed, 16 Jan 2013 11:21:44 -0800	[thread overview]
Message-ID: <50F6FDC8.5020909@parallels.com> (raw)
In-Reply-To: <1354058086-27937-10-git-send-email-david@fromorbit.com>

On 11/27/2012 03:14 PM, Dave Chinner wrote:
> From: Dave Chinner <dchinner@redhat.com>
> 
> Now that we have an LRU list API, we can start to enhance the
> implementation.  This splits the single LRU list into per-node lists
> and locks to enhance scalability. Items are placed on lists
> according to the node the memory belongs to. To make scanning the
> lists efficient, also track whether the per-node lists have entries
> in them in a active nodemask.
> 
> Signed-off-by: Dave Chinner <dchinner@redhat.com>
> ---
>  include/linux/list_lru.h |   14 ++--
>  lib/list_lru.c           |  160 +++++++++++++++++++++++++++++++++++-----------
>  2 files changed, 129 insertions(+), 45 deletions(-)
> 
> diff --git a/include/linux/list_lru.h b/include/linux/list_lru.h
> index 3423949..b0e3ba2 100644
> --- a/include/linux/list_lru.h
> +++ b/include/linux/list_lru.h
> @@ -8,21 +8,23 @@
>  #define _LRU_LIST_H 0
>  
>  #include <linux/list.h>
> +#include <linux/nodemask.h>
>  
> -struct list_lru {
> +struct list_lru_node {
>  	spinlock_t		lock;
>  	struct list_head	list;
>  	long			nr_items;
> +} ____cacheline_aligned_in_smp;
> +
> +struct list_lru {
> +	struct list_lru_node	node[MAX_NUMNODES];
> +	nodemask_t		active_nodes;
>  };
>  
MAX_NUMNODES will default to 1 << 9, if I'm not mistaken. Your
list_lru_node seems to be around 32 bytes on 64-bit systems (128 with
debug). So we're talking about 16k per lru.
The superblocks only, are present by the dozens even in a small system,
and I believe the whole goal of this API is to get more users to switch
to it. This can easily use up a respectable bunch of megs.

Isn't it a bit too much ?

I am wondering if we can't do better in here and at least allocate+grow
according to the actual number of nodes.

--
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: Glauber Costa <glommer@parallels.com>
To: Dave Chinner <david@fromorbit.com>
Cc: <linux-kernel@vger.kernel.org>, <linux-fsdevel@vger.kernel.org>,
	<linux-mm@kvack.org>, <xfs@oss.sgi.com>,
	Greg Thelen <gthelen@google.com>, Ying Han <yinghan@google.com>,
	Suleiman Souhlal <suleiman@google.com>
Subject: Re: [PATCH 09/19] list_lru: per-node list infrastructure
Date: Wed, 16 Jan 2013 11:21:44 -0800	[thread overview]
Message-ID: <50F6FDC8.5020909@parallels.com> (raw)
In-Reply-To: <1354058086-27937-10-git-send-email-david@fromorbit.com>

On 11/27/2012 03:14 PM, Dave Chinner wrote:
> From: Dave Chinner <dchinner@redhat.com>
> 
> Now that we have an LRU list API, we can start to enhance the
> implementation.  This splits the single LRU list into per-node lists
> and locks to enhance scalability. Items are placed on lists
> according to the node the memory belongs to. To make scanning the
> lists efficient, also track whether the per-node lists have entries
> in them in a active nodemask.
> 
> Signed-off-by: Dave Chinner <dchinner@redhat.com>
> ---
>  include/linux/list_lru.h |   14 ++--
>  lib/list_lru.c           |  160 +++++++++++++++++++++++++++++++++++-----------
>  2 files changed, 129 insertions(+), 45 deletions(-)
> 
> diff --git a/include/linux/list_lru.h b/include/linux/list_lru.h
> index 3423949..b0e3ba2 100644
> --- a/include/linux/list_lru.h
> +++ b/include/linux/list_lru.h
> @@ -8,21 +8,23 @@
>  #define _LRU_LIST_H 0
>  
>  #include <linux/list.h>
> +#include <linux/nodemask.h>
>  
> -struct list_lru {
> +struct list_lru_node {
>  	spinlock_t		lock;
>  	struct list_head	list;
>  	long			nr_items;
> +} ____cacheline_aligned_in_smp;
> +
> +struct list_lru {
> +	struct list_lru_node	node[MAX_NUMNODES];
> +	nodemask_t		active_nodes;
>  };
>  
MAX_NUMNODES will default to 1 << 9, if I'm not mistaken. Your
list_lru_node seems to be around 32 bytes on 64-bit systems (128 with
debug). So we're talking about 16k per lru.
The superblocks only, are present by the dozens even in a small system,
and I believe the whole goal of this API is to get more users to switch
to it. This can easily use up a respectable bunch of megs.

Isn't it a bit too much ?

I am wondering if we can't do better in here and at least allocate+grow
according to the actual number of nodes.


  parent reply	other threads:[~2013-01-16 19:21 UTC|newest]

Thread overview: 163+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-11-27 23:14 [RFC, PATCH 00/19] Numa aware LRU lists and shrinkers Dave Chinner
2012-11-27 23:14 ` Dave Chinner
2012-11-27 23:14 ` Dave Chinner
2012-11-27 23:14 ` [PATCH 01/19] dcache: convert dentry_stat.nr_unused to per-cpu counters Dave Chinner
2012-11-27 23:14   ` Dave Chinner
2012-11-27 23:14   ` Dave Chinner
2012-11-27 23:14 ` [PATCH 02/19] dentry: move to per-sb LRU locks Dave Chinner
2012-11-27 23:14   ` Dave Chinner
2012-11-27 23:14   ` Dave Chinner
2012-11-27 23:14 ` [PATCH 03/19] dcache: remove dentries from LRU before putting on dispose list Dave Chinner
2012-11-27 23:14   ` Dave Chinner
2012-11-27 23:14   ` Dave Chinner
2012-11-27 23:14 ` [PATCH 04/19] mm: new shrinker API Dave Chinner
2012-11-27 23:14   ` Dave Chinner
2012-11-27 23:14   ` Dave Chinner
2012-11-27 23:14 ` [PATCH 05/19] shrinker: convert superblock shrinkers to new API Dave Chinner
2012-11-27 23:14   ` Dave Chinner
2012-11-27 23:14   ` Dave Chinner
2012-12-20 11:06   ` Glauber Costa
2012-12-20 11:06     ` Glauber Costa
2012-12-20 11:06     ` Glauber Costa
2012-12-21  1:46     ` Dave Chinner
2012-12-21  1:46       ` Dave Chinner
2012-12-21 10:17       ` Glauber Costa
2012-12-21 10:17         ` Glauber Costa
2012-12-21 10:17         ` Glauber Costa
2012-11-27 23:14 ` [PATCH 06/19] list: add a new LRU list type Dave Chinner
2012-11-27 23:14   ` Dave Chinner
2012-11-27 23:14   ` Dave Chinner
2012-11-28 16:10   ` Christoph Hellwig
2012-11-28 16:10     ` Christoph Hellwig
2012-11-28 16:10     ` Christoph Hellwig
2012-11-27 23:14 ` [PATCH 07/19] inode: convert inode lru list to generic lru list code Dave Chinner
2012-11-27 23:14   ` Dave Chinner
2012-11-27 23:14   ` Dave Chinner
2012-11-27 23:14 ` [PATCH 08/19] dcache: convert to use new lru list infrastructure Dave Chinner
2012-11-27 23:14   ` Dave Chinner
2012-11-27 23:14   ` Dave Chinner
2012-11-27 23:14 ` [PATCH 09/19] list_lru: per-node " Dave Chinner
2012-11-27 23:14   ` Dave Chinner
2012-11-27 23:14   ` Dave Chinner
2012-12-20 11:21   ` Glauber Costa
2012-12-20 11:21     ` Glauber Costa
2012-12-20 11:21     ` Glauber Costa
2012-12-21  1:54     ` Dave Chinner
2012-12-21  1:54       ` Dave Chinner
2013-01-16 19:21   ` Glauber Costa [this message]
2013-01-16 19:21     ` Glauber Costa
2013-01-16 19:21     ` Glauber Costa
2013-01-16 22:55     ` Dave Chinner
2013-01-16 22:55       ` Dave Chinner
2013-01-17  0:35       ` Glauber Costa
2013-01-17  0:35         ` Glauber Costa
2013-01-17  0:35         ` Glauber Costa
2013-01-17  4:22         ` Dave Chinner
2013-01-17  4:22           ` Dave Chinner
2013-01-17 18:21           ` Glauber Costa
2013-01-17 18:21             ` Glauber Costa
2013-01-17 18:21             ` Glauber Costa
2013-01-18  0:10             ` Dave Chinner
2013-01-18  0:10               ` Dave Chinner
2013-01-18  0:14               ` Glauber Costa
2013-01-18  0:14                 ` Glauber Costa
2013-01-18  0:14                 ` Glauber Costa
2013-01-18  8:11                 ` Dave Chinner
2013-01-18  8:11                   ` Dave Chinner
2013-01-18 19:10                   ` Glauber Costa
2013-01-18 19:10                     ` Glauber Costa
2013-01-18 19:10                     ` Glauber Costa
2013-01-19  0:10                     ` Dave Chinner
2013-01-19  0:10                       ` Dave Chinner
2013-01-19  0:13                       ` Glauber Costa
2013-01-19  0:13                         ` Glauber Costa
2013-01-19  0:13                         ` Glauber Costa
2013-01-18  0:51               ` Glauber Costa
2013-01-18  0:51                 ` Glauber Costa
2013-01-18  0:51                 ` Glauber Costa
2013-01-18  8:08                 ` Dave Chinner
2013-01-18  8:08                   ` Dave Chinner
2013-01-18 19:01                   ` Glauber Costa
2013-01-18 19:01                     ` Glauber Costa
2013-01-18 19:01                     ` Glauber Costa
2012-11-27 23:14 ` [PATCH 10/19] shrinker: add node awareness Dave Chinner
2012-11-27 23:14   ` Dave Chinner
2012-11-27 23:14   ` Dave Chinner
2012-11-27 23:14 ` [PATCH 11/19] fs: convert inode and dentry shrinking to be node aware Dave Chinner
2012-11-27 23:14   ` Dave Chinner
2012-11-27 23:14   ` Dave Chinner
2012-11-27 23:14 ` [PATCH 12/19] xfs: convert buftarg LRU to generic code Dave Chinner
2012-11-27 23:14   ` Dave Chinner
2012-11-27 23:14   ` Dave Chinner
2012-11-27 23:14 ` [PATCH 13/19] xfs: Node aware direct inode reclaim Dave Chinner
2012-11-27 23:14   ` Dave Chinner
2012-11-27 23:14   ` Dave Chinner
2012-11-27 23:14 ` [PATCH 14/19] xfs: use generic AG walk for background " Dave Chinner
2012-11-27 23:14   ` Dave Chinner
2012-11-27 23:14   ` Dave Chinner
2012-11-27 23:14 ` [PATCH 15/19] xfs: convert dquot cache lru to list_lru Dave Chinner
2012-11-27 23:14   ` Dave Chinner
2012-11-27 23:14   ` Dave Chinner
2012-11-28 16:17   ` Christoph Hellwig
2012-11-28 16:17     ` Christoph Hellwig
2012-11-28 16:17     ` Christoph Hellwig
2012-11-27 23:14 ` [PATCH 16/19] fs: convert fs shrinkers to new scan/count API Dave Chinner
2012-11-27 23:14   ` Dave Chinner
2012-11-27 23:14   ` Dave Chinner
2012-11-27 23:14 ` [PATCH 17/19] drivers: convert shrinkers to new count/scan API Dave Chinner
2012-11-27 23:14   ` Dave Chinner
2012-11-27 23:14   ` Dave Chinner
2012-11-28  1:13   ` Chris Wilson
2012-11-28  1:13     ` Chris Wilson
2012-11-28  1:13     ` Chris Wilson
2012-11-28  3:17     ` Dave Chinner
2012-11-28  3:17       ` Dave Chinner
2012-11-28  3:17       ` Dave Chinner
2012-11-28  8:21       ` Glauber Costa
2012-11-28  8:21         ` Glauber Costa
2012-11-28  8:21         ` Glauber Costa
2012-11-28  8:21         ` Glauber Costa
2012-11-28 21:28         ` Dave Chinner
2012-11-28 21:28           ` Dave Chinner
2012-11-28 21:28           ` Dave Chinner
2012-11-29 10:29           ` Glauber Costa
2012-11-29 10:29             ` Glauber Costa
2012-11-29 10:29             ` Glauber Costa
2012-11-29 10:29             ` Glauber Costa
2012-11-29 22:02             ` Dave Chinner
2012-11-29 22:02               ` Dave Chinner
2012-11-29 22:02               ` Dave Chinner
2013-06-07 13:37   ` Konrad Rzeszutek Wilk
2013-06-07 13:37     ` Konrad Rzeszutek Wilk
2013-06-07 13:37     ` Konrad Rzeszutek Wilk
2012-11-27 23:14 ` [PATCH 18/19] shrinker: convert remaining shrinkers to " Dave Chinner
2012-11-27 23:14   ` Dave Chinner
2012-11-27 23:14   ` Dave Chinner
2012-11-27 23:14 ` [PATCH 19/19] shrinker: Kill old ->shrink API Dave Chinner
2012-11-27 23:14   ` Dave Chinner
2012-11-27 23:14   ` Dave Chinner
2012-11-29 19:02 ` [RFC, PATCH 00/19] Numa aware LRU lists and shrinkers Andi Kleen
2012-11-29 19:02   ` Andi Kleen
2012-11-29 19:02   ` Andi Kleen
2012-11-29 22:09   ` Dave Chinner
2012-11-29 22:09     ` Dave Chinner
2012-11-29 22:09     ` Dave Chinner
2012-12-20 11:45 ` Glauber Costa
2012-12-20 11:45   ` Glauber Costa
2012-12-20 11:45   ` Glauber Costa
2012-12-21  2:50   ` Dave Chinner
2012-12-21  2:50     ` Dave Chinner
2012-12-21 10:41     ` Glauber Costa
2012-12-21 10:41       ` Glauber Costa
2012-12-21 10:41       ` Glauber Costa
2013-01-21 16:08 ` Glauber Costa
2013-01-21 16:08   ` Glauber Costa
2013-01-21 16:08   ` Glauber Costa
2013-01-21 23:21   ` Dave Chinner
2013-01-21 23:21     ` Dave Chinner
2013-01-21 23:21     ` Dave Chinner
2013-01-23 14:36     ` Glauber Costa
2013-01-23 14:36       ` Glauber Costa
2013-01-23 14:36       ` Glauber Costa
2013-01-23 23:46       ` Dave Chinner
2013-01-23 23:46         ` Dave Chinner

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=50F6FDC8.5020909@parallels.com \
    --to=glommer@parallels.com \
    --cc=david@fromorbit.com \
    --cc=gthelen@google.com \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=suleiman@google.com \
    --cc=xfs@oss.sgi.com \
    --cc=yinghan@google.com \
    /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.