From: Christoph Lameter <cl@linux-foundation.org>
To: Brice Goglin <Brice.Goglin@inria.fr>
Cc: Andrew Morton <akpm@linux-foundation.org>,
linux-kernel@vger.kernel.org, linux-mm@kvack.org,
nathalie.furmento@labri.fr
Subject: Re: [PATCH] mm: use a radix-tree to make do_move_pages() complexity linear
Date: Fri, 10 Oct 2008 15:32:41 -0500 [thread overview]
Message-ID: <48EFBBE9.5000703@linux-foundation.org> (raw)
In-Reply-To: <48EFB6E6.4080708@inria.fr>
Brice Goglin wrote:
> Just try sys_move_pages() on a 10-100MB buffer, you'll get something
> like 50MB/s on a recent Opteron machine. This throughput decreases
> significantly with the number of pages. With this patch, we get about
> 350MB/s and the throughput is stable when the migrated buffer gets
> larger. I don't have detailled numbers at hand, I'll send them by monday.
Migration throughput is optimal for sys_move_pages() and the cpuset migration.
Some comparison would be useful.
With 100MB you have ~250k pages which will require a vmalloc of 4MB for the
struct pm struct array to control the migration of each individual page.
Would it be possible to restructure this in such a way that we work in chunks
of 100 or so pages each so that we can avoid the vmalloc?
We also could do a kmalloc for each individual struct pm_struct with the radix
tree which would also avoid the vmalloc but still keep the need to allocate
4MB for temporary struct pm_structs.
Or get rid of the pm_struct altogether by storing the address of the node
vector somewhere and retrieve the node as needed from the array. This would
allow storing the struct page * pointers in the radix tree.
WARNING: multiple messages have this Message-ID (diff)
From: Christoph Lameter <cl@linux-foundation.org>
To: Brice Goglin <Brice.Goglin@inria.fr>
Cc: Andrew Morton <akpm@linux-foundation.org>,
linux-kernel@vger.kernel.org, linux-mm@kvack.org,
nathalie.furmento@labri.fr
Subject: Re: [PATCH] mm: use a radix-tree to make do_move_pages() complexity linear
Date: Fri, 10 Oct 2008 15:32:41 -0500 [thread overview]
Message-ID: <48EFBBE9.5000703@linux-foundation.org> (raw)
In-Reply-To: <48EFB6E6.4080708@inria.fr>
Brice Goglin wrote:
> Just try sys_move_pages() on a 10-100MB buffer, you'll get something
> like 50MB/s on a recent Opteron machine. This throughput decreases
> significantly with the number of pages. With this patch, we get about
> 350MB/s and the throughput is stable when the migrated buffer gets
> larger. I don't have detailled numbers at hand, I'll send them by monday.
Migration throughput is optimal for sys_move_pages() and the cpuset migration.
Some comparison would be useful.
With 100MB you have ~250k pages which will require a vmalloc of 4MB for the
struct pm struct array to control the migration of each individual page.
Would it be possible to restructure this in such a way that we work in chunks
of 100 or so pages each so that we can avoid the vmalloc?
We also could do a kmalloc for each individual struct pm_struct with the radix
tree which would also avoid the vmalloc but still keep the need to allocate
4MB for temporary struct pm_structs.
Or get rid of the pm_struct altogether by storing the address of the node
vector somewhere and retrieve the node as needed from the array. This would
allow storing the struct page * pointers in the radix tree.
--
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>
next prev parent reply other threads:[~2008-10-10 20:34 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-10-09 12:32 [PATCH] mm: use a radix-tree to make do_move_pages() complexity linear Brice Goglin
2008-10-09 12:32 ` Brice Goglin
2008-10-10 19:50 ` Andrew Morton
2008-10-10 19:50 ` Andrew Morton
2008-10-10 20:11 ` Brice Goglin
2008-10-10 20:11 ` Brice Goglin
2008-10-10 20:32 ` Christoph Lameter [this message]
2008-10-10 20:32 ` Christoph Lameter
2008-10-11 8:54 ` Brice Goglin
2008-10-11 8:54 ` Brice Goglin
2008-10-11 8:58 ` Nick Piggin
2008-10-11 8:58 ` Nick Piggin
2008-10-11 9:19 ` Brice Goglin
2008-10-11 9:19 ` Brice Goglin
2008-10-13 16:09 ` Christoph Lameter
2008-10-13 16:09 ` Christoph Lameter
2008-10-10 20:59 ` Brice Goglin
2008-10-10 20:59 ` Brice Goglin
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=48EFBBE9.5000703@linux-foundation.org \
--to=cl@linux-foundation.org \
--cc=Brice.Goglin@inria.fr \
--cc=akpm@linux-foundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=nathalie.furmento@labri.fr \
/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.