From: Nathan Zimmer <nzimmer@sgi.com>
To: linux-mm@kvack.org, linux-kernel@vger.kernel.org
Cc: Christoph Lameter <cl@linux.com>, Nick Piggin <npiggin@gmail.com>,
Hugh Dickins <hughd@google.com>,
Lee Schermerhorn <lee.schermerhorn@hp.com>,
KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>,
Rik van Riel <riel@redhat.com>
Subject: Re: [PATCH 0/2 v4][rfc] tmpfs not interleaving properly
Date: Mon, 2 Jul 2012 15:54:20 -0500 [thread overview]
Message-ID: <4FF20A7C.7070801@sgi.com> (raw)
In-Reply-To: <20120702202635.GA20284@gulag1.americas.sgi.com>
On 07/02/2012 03:26 PM, Nathan Zimmer wrote:
> When tmpfs has the memory policy interleaved it always starts allocating at each
> file at node 0. When there are many small files the lower nodes fill up
> disproportionately.
> This patch spreads out node usage by starting files at nodes other then 0.
> The tmpfs superblock grants an offset for each inode as they are created. Each
> then uses that offset to proved a prefered first node for its interleave in
> the shmem_interleave.
>
> v2: passed preferred node via addr
> v3: using current->cpuset_mem_spread_rotor instead of random_node
> v4: Switching the rotor and attempting to provide an interleave function
> Also splitting the patch into two sections.
>
> Cc: Christoph Lameter <cl@linux.com>
> Cc: Nick Piggin <npiggin@gmail.com>
> Cc: Hugh Dickins <hughd@google.com>
> Cc: Lee Schermerhorn <lee.schermerhorn@hp.com>
> Cc: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
> Cc: Rik van Riel <riel@redhat.com>
> Cc: Andrew Morton <akpm@linux-foundation.org>
> Signed-off-by: Nathan T Zimmer <nzimmer@sgi.com>
> ---
>
> include/linux/mm.h | 6 ++++++
> include/linux/shmem_fs.h | 2 ++
> mm/mempolicy.c | 4 ++++
> mm/shmem.c | 33 ++++++++++++++++++++++++++++++---
> 4 files changed, 42 insertions(+), 3 deletions(-)
>
> --
> 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>
I apologize, it seems I have sent the patch before running checkpatch.
--
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: Nathan Zimmer <nzimmer@sgi.com>
To: <linux-mm@kvack.org>, <linux-kernel@vger.kernel.org>
Cc: Christoph Lameter <cl@linux.com>, Nick Piggin <npiggin@gmail.com>,
Hugh Dickins <hughd@google.com>,
Lee Schermerhorn <lee.schermerhorn@hp.com>,
KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>,
Rik van Riel <riel@redhat.com>
Subject: Re: [PATCH 0/2 v4][rfc] tmpfs not interleaving properly
Date: Mon, 2 Jul 2012 15:54:20 -0500 [thread overview]
Message-ID: <4FF20A7C.7070801@sgi.com> (raw)
In-Reply-To: <20120702202635.GA20284@gulag1.americas.sgi.com>
On 07/02/2012 03:26 PM, Nathan Zimmer wrote:
> When tmpfs has the memory policy interleaved it always starts allocating at each
> file at node 0. When there are many small files the lower nodes fill up
> disproportionately.
> This patch spreads out node usage by starting files at nodes other then 0.
> The tmpfs superblock grants an offset for each inode as they are created. Each
> then uses that offset to proved a prefered first node for its interleave in
> the shmem_interleave.
>
> v2: passed preferred node via addr
> v3: using current->cpuset_mem_spread_rotor instead of random_node
> v4: Switching the rotor and attempting to provide an interleave function
> Also splitting the patch into two sections.
>
> Cc: Christoph Lameter <cl@linux.com>
> Cc: Nick Piggin <npiggin@gmail.com>
> Cc: Hugh Dickins <hughd@google.com>
> Cc: Lee Schermerhorn <lee.schermerhorn@hp.com>
> Cc: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
> Cc: Rik van Riel <riel@redhat.com>
> Cc: Andrew Morton <akpm@linux-foundation.org>
> Signed-off-by: Nathan T Zimmer <nzimmer@sgi.com>
> ---
>
> include/linux/mm.h | 6 ++++++
> include/linux/shmem_fs.h | 2 ++
> mm/mempolicy.c | 4 ++++
> mm/shmem.c | 33 ++++++++++++++++++++++++++++++---
> 4 files changed, 42 insertions(+), 3 deletions(-)
>
> --
> 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>
I apologize, it seems I have sent the patch before running checkpatch.
next prev parent reply other threads:[~2012-07-02 20:54 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-07-02 20:26 [PATCH 0/2 v4][rfc] tmpfs not interleaving properly Nathan Zimmer
2012-07-02 20:26 ` Nathan Zimmer
2012-07-02 20:28 ` [PATCH 1/2 v4][rfc] shmem: provide vm_ops when also providing a mem policy Nathan Zimmer
2012-07-02 20:28 ` Nathan Zimmer
2012-07-02 20:28 ` [PATCH 2/2 v4][rfc] tmpfs: interleave the starting node of /dev/shmem Nathan Zimmer
2012-07-02 20:28 ` Nathan Zimmer
2012-07-03 12:49 ` Cong Wang
2012-07-02 20:54 ` Nathan Zimmer [this message]
2012-07-02 20:54 ` [PATCH 0/2 v4][rfc] tmpfs not interleaving properly Nathan Zimmer
2012-07-03 10:32 ` Cong Wang
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=4FF20A7C.7070801@sgi.com \
--to=nzimmer@sgi.com \
--cc=cl@linux.com \
--cc=hughd@google.com \
--cc=kosaki.motohiro@jp.fujitsu.com \
--cc=lee.schermerhorn@hp.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=npiggin@gmail.com \
--cc=riel@redhat.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.