From: dave@linux.vnet.ibm.com (Dave Hansen)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 2/8] mm: alloc_contig_freed_pages() added
Date: Wed, 21 Sep 2011 07:07:36 -0700 [thread overview]
Message-ID: <1316614056.16137.278.camel@nimitz> (raw)
In-Reply-To: <op.v15tv0183l0zgt@mnazarewicz-glaptop>
On Wed, 2011-09-21 at 15:17 +0200, Michal Nazarewicz wrote:
> > This 'struct page *'++ stuff is OK, but only for small, aligned areas.
> > For at least some of the sparsemem modes (non-VMEMMAP), you could walk
> > off of the end of the section_mem_map[] when you cross a MAX_ORDER
> > boundary. I'd feel a little bit more comfortable if pfn_to_page() was
> > being done each time, or only occasionally when you cross a section
> > boundary.
>
> I'm fine with that. I've used pointer arithmetic for performance reasons
> but if that may potentially lead to bugs then obviously pfn_to_page()
> should be used
pfn_to_page() on x86 these days is usually:
#define __pfn_to_page(pfn) (vmemmap + (pfn))
Even for the non-vmemmap sparsemem it stays pretty quick because the
section array is in cache as you run through the loop.
There are ways to _minimize_ the number of pfn_to_page() calls by
checking when you cross a section boundary, or even at a
MAX_ORDER_NR_PAGES boundary. But, I don't think it's worth the trouble.
-- Dave
WARNING: multiple messages have this Message-ID (diff)
From: Dave Hansen <dave@linux.vnet.ibm.com>
To: Michal Nazarewicz <mina86@mina86.com>
Cc: Marek Szyprowski <m.szyprowski@samsung.com>,
linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
linux-media@vger.kernel.org, linux-mm@kvack.org,
linaro-mm-sig@lists.linaro.org,
Kyungmin Park <kyungmin.park@samsung.com>,
Russell King <linux@arm.linux.org.uk>,
Andrew Morton <akpm@linux-foundation.org>,
KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>,
Ankita Garg <ankita@in.ibm.com>,
Daniel Walker <dwalker@codeaurora.org>,
Mel Gorman <mel@csn.ul.ie>, Arnd Bergmann <arnd@arndb.de>,
Jesse Barker <jesse.barker@linaro.org>,
Jonathan Corbet <corbet@lwn.net>,
Shariq Hasnain <shariq.hasnain@linaro.org>,
Chunsang Jeong <chunsang.jeong@linaro.org>
Subject: Re: [PATCH 2/8] mm: alloc_contig_freed_pages() added
Date: Wed, 21 Sep 2011 07:07:36 -0700 [thread overview]
Message-ID: <1316614056.16137.278.camel@nimitz> (raw)
In-Reply-To: <op.v15tv0183l0zgt@mnazarewicz-glaptop>
On Wed, 2011-09-21 at 15:17 +0200, Michal Nazarewicz wrote:
> > This 'struct page *'++ stuff is OK, but only for small, aligned areas.
> > For at least some of the sparsemem modes (non-VMEMMAP), you could walk
> > off of the end of the section_mem_map[] when you cross a MAX_ORDER
> > boundary. I'd feel a little bit more comfortable if pfn_to_page() was
> > being done each time, or only occasionally when you cross a section
> > boundary.
>
> I'm fine with that. I've used pointer arithmetic for performance reasons
> but if that may potentially lead to bugs then obviously pfn_to_page()
> should be used
pfn_to_page() on x86 these days is usually:
#define __pfn_to_page(pfn) (vmemmap + (pfn))
Even for the non-vmemmap sparsemem it stays pretty quick because the
section array is in cache as you run through the loop.
There are ways to _minimize_ the number of pfn_to_page() calls by
checking when you cross a section boundary, or even at a
MAX_ORDER_NR_PAGES boundary. But, I don't think it's worth the trouble.
-- Dave
WARNING: multiple messages have this Message-ID (diff)
From: Dave Hansen <dave@linux.vnet.ibm.com>
To: Michal Nazarewicz <mina86@mina86.com>
Cc: Marek Szyprowski <m.szyprowski@samsung.com>,
linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
linux-media@vger.kernel.org, linux-mm@kvack.org,
linaro-mm-sig@lists.linaro.org,
Kyungmin Park <kyungmin.park@samsung.com>,
Russell King <linux@arm.linux.org.uk>,
Andrew Morton <akpm@linux-foundation.org>,
KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>,
Ankita Garg <ankita@in.ibm.com>,
Daniel Walker <dwalker@codeaurora.org>,
Mel Gorman <mel@csn.ul.ie>, Arnd Bergmann <arnd@arndb.de>,
Jesse Barker <jesse.barker@linaro.org>,
Jonathan Corbet <corbet@lwn.net>,
Shariq Hasnain <shariq.hasnain@linaro.org>,
Chunsang Jeong <chunsang.jeong@linaro.org>
Subject: Re: [PATCH 2/8] mm: alloc_contig_freed_pages() added
Date: Wed, 21 Sep 2011 07:07:36 -0700 [thread overview]
Message-ID: <1316614056.16137.278.camel@nimitz> (raw)
In-Reply-To: <op.v15tv0183l0zgt@mnazarewicz-glaptop>
On Wed, 2011-09-21 at 15:17 +0200, Michal Nazarewicz wrote:
> > This 'struct page *'++ stuff is OK, but only for small, aligned areas.
> > For at least some of the sparsemem modes (non-VMEMMAP), you could walk
> > off of the end of the section_mem_map[] when you cross a MAX_ORDER
> > boundary. I'd feel a little bit more comfortable if pfn_to_page() was
> > being done each time, or only occasionally when you cross a section
> > boundary.
>
> I'm fine with that. I've used pointer arithmetic for performance reasons
> but if that may potentially lead to bugs then obviously pfn_to_page()
> should be used
pfn_to_page() on x86 these days is usually:
#define __pfn_to_page(pfn) (vmemmap + (pfn))
Even for the non-vmemmap sparsemem it stays pretty quick because the
section array is in cache as you run through the loop.
There are ways to _minimize_ the number of pfn_to_page() calls by
checking when you cross a section boundary, or even at a
MAX_ORDER_NR_PAGES boundary. But, I don't think it's worth the trouble.
-- Dave
--
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>
next prev parent reply other threads:[~2011-09-21 14:07 UTC|newest]
Thread overview: 62+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-08-19 14:27 [PATCHv15 0/8] Contiguous Memory Allocator Marek Szyprowski
2011-08-19 14:27 ` Marek Szyprowski
2011-08-19 14:27 ` Marek Szyprowski
2011-08-19 14:27 ` [PATCH 1/8] mm: move some functions from memory_hotplug.c to page_isolation.c Marek Szyprowski
2011-08-19 14:27 ` Marek Szyprowski
2011-08-19 14:27 ` Marek Szyprowski
2011-08-19 14:27 ` [PATCH 2/8] mm: alloc_contig_freed_pages() added Marek Szyprowski
2011-08-19 14:27 ` Marek Szyprowski
2011-08-19 14:27 ` Marek Szyprowski
2011-09-08 18:05 ` Dave Hansen
2011-09-08 18:05 ` Dave Hansen
2011-09-08 18:05 ` Dave Hansen
2011-09-21 13:17 ` Michal Nazarewicz
2011-09-21 13:17 ` Michal Nazarewicz
2011-09-21 13:17 ` Michal Nazarewicz
2011-09-21 14:07 ` Dave Hansen [this message]
2011-09-21 14:07 ` Dave Hansen
2011-09-21 14:07 ` Dave Hansen
2011-09-21 15:19 ` [PATCH 1/3] fixup! " Michal Nazarewicz
2011-09-21 15:19 ` Michal Nazarewicz
2011-09-21 15:19 ` Michal Nazarewicz
2011-09-21 15:45 ` Dave Hansen
2011-09-21 15:45 ` Dave Hansen
2011-09-21 15:45 ` Dave Hansen
2011-09-21 16:26 ` Michal Nazarewicz
2011-09-21 16:26 ` Michal Nazarewicz
2011-09-21 16:26 ` Michal Nazarewicz
2011-09-21 16:30 ` Dave Hansen
2011-09-21 16:30 ` Dave Hansen
2011-09-21 16:30 ` Dave Hansen
2011-08-19 14:27 ` [PATCH 3/8] mm: alloc_contig_range() added Marek Szyprowski
2011-08-19 14:27 ` Marek Szyprowski
2011-08-19 14:27 ` Marek Szyprowski
2011-08-19 14:27 ` [PATCH 4/8] mm: MIGRATE_CMA migration type added Marek Szyprowski
2011-08-19 14:27 ` Marek Szyprowski
2011-08-19 14:27 ` Marek Szyprowski
2011-08-19 14:27 ` [PATCH 5/8] mm: MIGRATE_CMA isolation functions added Marek Szyprowski
2011-08-19 14:27 ` Marek Szyprowski
2011-08-19 14:27 ` Marek Szyprowski
2011-08-19 14:27 ` [PATCH 6/8] drivers: add Contiguous Memory Allocator Marek Szyprowski
2011-08-19 14:27 ` Marek Szyprowski
2011-08-19 14:27 ` Marek Szyprowski
2011-08-19 14:27 ` [PATCH 7/8] ARM: integrate CMA with DMA-mapping subsystem Marek Szyprowski
2011-08-19 14:27 ` Marek Szyprowski
2011-08-19 14:27 ` Marek Szyprowski
2011-09-08 17:27 ` Mike Frysinger
2011-09-08 17:27 ` Mike Frysinger
2011-09-21 13:47 ` Marek Szyprowski
2011-09-21 13:47 ` Marek Szyprowski
2011-09-21 13:47 ` Marek Szyprowski
2011-08-19 14:27 ` [PATCH 8/8] ARM: S5PV210: example of CMA private area for FIMC device on Goni board Marek Szyprowski
2011-08-19 14:27 ` Marek Szyprowski
2011-08-19 14:27 ` Marek Szyprowski
-- strict thread matches above, loose matches on Subject: below --
2011-07-20 8:57 [PATCHv12 0/8] Contiguous Memory Allocator Marek Szyprowski
2011-07-20 8:57 ` [PATCH 2/8] mm: alloc_contig_freed_pages() added Marek Szyprowski
2011-07-20 8:57 ` Marek Szyprowski
2011-07-20 8:57 ` Marek Szyprowski
2011-07-05 7:41 [PATCHv11 0/8] Contiguous Memory Allocator Marek Szyprowski
2011-07-05 7:41 ` [PATCH 2/8] mm: alloc_contig_freed_pages() added Marek Szyprowski
2011-07-05 7:41 ` Marek Szyprowski
2011-07-05 7:41 ` Marek Szyprowski
2011-07-05 11:30 ` Arnd Bergmann
2011-07-05 11:30 ` Arnd Bergmann
2011-07-05 11:30 ` Arnd Bergmann
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=1316614056.16137.278.camel@nimitz \
--to=dave@linux.vnet.ibm.com \
--cc=linux-arm-kernel@lists.infradead.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.