All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Michal Nazarewicz" <mina86@mina86.com>
To: "Marek Szyprowski" <m.szyprowski@samsung.com>,
	"Dave Hansen" <dave@linux.vnet.ibm.com>
Cc: 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 15:17:50 +0200	[thread overview]
Message-ID: <op.v15tv0183l0zgt@mnazarewicz-glaptop> (raw)
In-Reply-To: <1315505152.3114.9.camel@nimitz>

On Thu, 08 Sep 2011 20:05:52 +0200, Dave Hansen <dave@linux.vnet.ibm.com>  
wrote:

> On Fri, 2011-08-19 at 16:27 +0200, Marek Szyprowski wrote:
>> +unsigned long alloc_contig_freed_pages(unsigned long start, unsigned  
>> long end,
>> +				       gfp_t flag)
>> +{
>> +	unsigned long pfn = start, count;
>> +	struct page *page;
>> +	struct zone *zone;
>> +	int order;
>> +
>> +	VM_BUG_ON(!pfn_valid(start));
>> +	zone = page_zone(pfn_to_page(start));
>
> This implies that start->end are entirely contained in a single zone.
> What enforces that?

In case of CMA, the __cma_activate_area() function from 6/8 has the check:

  151                         VM_BUG_ON(!pfn_valid(pfn));
  152                         VM_BUG_ON(page_zone(pfn_to_page(pfn)) !=  
zone);

This guarantees that CMA will never try to call alloc_contig_freed_pages()
on a region that spans multiple regions.

> If some higher layer enforces that, I think we probably need at least
> a VM_BUG_ON() in here and a comment about who enforces it.

Agreed.

>> +	spin_lock_irq(&zone->lock);
>> +
>> +	page = pfn_to_page(pfn);
>> +	for (;;) {
>> +		VM_BUG_ON(page_count(page) || !PageBuddy(page));
>> +		list_del(&page->lru);
>> +		order = page_order(page);
>> +		zone->free_area[order].nr_free--;
>> +		rmv_page_order(page);
>> +		__mod_zone_page_state(zone, NR_FREE_PAGES, -(1UL << order));
>> +		pfn  += 1 << order;
>> +		if (pfn >= end)
>> +			break;
>> +		VM_BUG_ON(!pfn_valid(pfn));
>> +		page += 1 << order;
>> +	}

> 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.

-- 
Best regards,                                         _     _
.o. | Liege of Serenely Enlightened Majesty of      o' \,=./ `o
..o | Computer Science,  Michal "mina86" Nazarewicz    (o o)
ooo +-----<email/xmpp: mnazarewicz@google.com>-----ooO--(_)--Ooo--

WARNING: multiple messages have this Message-ID (diff)
From: "Michal Nazarewicz" <mina86@mina86.com>
To: Marek Szyprowski <m.szyprowski@samsung.com>,
	Dave Hansen <dave@linux.vnet.ibm.com>
Cc: 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 15:17:50 +0200	[thread overview]
Message-ID: <op.v15tv0183l0zgt@mnazarewicz-glaptop> (raw)
In-Reply-To: <1315505152.3114.9.camel@nimitz>

On Thu, 08 Sep 2011 20:05:52 +0200, Dave Hansen <dave@linux.vnet.ibm.com>  
wrote:

> On Fri, 2011-08-19 at 16:27 +0200, Marek Szyprowski wrote:
>> +unsigned long alloc_contig_freed_pages(unsigned long start, unsigned  
>> long end,
>> +				       gfp_t flag)
>> +{
>> +	unsigned long pfn = start, count;
>> +	struct page *page;
>> +	struct zone *zone;
>> +	int order;
>> +
>> +	VM_BUG_ON(!pfn_valid(start));
>> +	zone = page_zone(pfn_to_page(start));
>
> This implies that start->end are entirely contained in a single zone.
> What enforces that?

In case of CMA, the __cma_activate_area() function from 6/8 has the check:

  151                         VM_BUG_ON(!pfn_valid(pfn));
  152                         VM_BUG_ON(page_zone(pfn_to_page(pfn)) !=  
zone);

This guarantees that CMA will never try to call alloc_contig_freed_pages()
on a region that spans multiple regions.

> If some higher layer enforces that, I think we probably need at least
> a VM_BUG_ON() in here and a comment about who enforces it.

Agreed.

>> +	spin_lock_irq(&zone->lock);
>> +
>> +	page = pfn_to_page(pfn);
>> +	for (;;) {
>> +		VM_BUG_ON(page_count(page) || !PageBuddy(page));
>> +		list_del(&page->lru);
>> +		order = page_order(page);
>> +		zone->free_area[order].nr_free--;
>> +		rmv_page_order(page);
>> +		__mod_zone_page_state(zone, NR_FREE_PAGES, -(1UL << order));
>> +		pfn  += 1 << order;
>> +		if (pfn >= end)
>> +			break;
>> +		VM_BUG_ON(!pfn_valid(pfn));
>> +		page += 1 << order;
>> +	}

> 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.

-- 
Best regards,                                         _     _
.o. | Liege of Serenely Enlightened Majesty of      o' \,=./ `o
..o | Computer Science,  Michal "mina86" Nazarewicz    (o o)
ooo +-----<email/xmpp: mnazarewicz@google.com>-----ooO--(_)--Ooo--

--
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>

WARNING: multiple messages have this Message-ID (diff)
From: mina86@mina86.com (Michal Nazarewicz)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 2/8] mm: alloc_contig_freed_pages() added
Date: Wed, 21 Sep 2011 15:17:50 +0200	[thread overview]
Message-ID: <op.v15tv0183l0zgt@mnazarewicz-glaptop> (raw)
In-Reply-To: <1315505152.3114.9.camel@nimitz>

On Thu, 08 Sep 2011 20:05:52 +0200, Dave Hansen <dave@linux.vnet.ibm.com>  
wrote:

> On Fri, 2011-08-19 at 16:27 +0200, Marek Szyprowski wrote:
>> +unsigned long alloc_contig_freed_pages(unsigned long start, unsigned  
>> long end,
>> +				       gfp_t flag)
>> +{
>> +	unsigned long pfn = start, count;
>> +	struct page *page;
>> +	struct zone *zone;
>> +	int order;
>> +
>> +	VM_BUG_ON(!pfn_valid(start));
>> +	zone = page_zone(pfn_to_page(start));
>
> This implies that start->end are entirely contained in a single zone.
> What enforces that?

In case of CMA, the __cma_activate_area() function from 6/8 has the check:

  151                         VM_BUG_ON(!pfn_valid(pfn));
  152                         VM_BUG_ON(page_zone(pfn_to_page(pfn)) !=  
zone);

This guarantees that CMA will never try to call alloc_contig_freed_pages()
on a region that spans multiple regions.

> If some higher layer enforces that, I think we probably need at least
> a VM_BUG_ON() in here and a comment about who enforces it.

Agreed.

>> +	spin_lock_irq(&zone->lock);
>> +
>> +	page = pfn_to_page(pfn);
>> +	for (;;) {
>> +		VM_BUG_ON(page_count(page) || !PageBuddy(page));
>> +		list_del(&page->lru);
>> +		order = page_order(page);
>> +		zone->free_area[order].nr_free--;
>> +		rmv_page_order(page);
>> +		__mod_zone_page_state(zone, NR_FREE_PAGES, -(1UL << order));
>> +		pfn  += 1 << order;
>> +		if (pfn >= end)
>> +			break;
>> +		VM_BUG_ON(!pfn_valid(pfn));
>> +		page += 1 << order;
>> +	}

> 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.

-- 
Best regards,                                         _     _
.o. | Liege of Serenely Enlightened Majesty of      o' \,=./ `o
..o | Computer Science,  Michal "mina86" Nazarewicz    (o o)
ooo +-----<email/xmpp: mnazarewicz@google.com>-----ooO--(_)--Ooo--

  reply	other threads:[~2011-09-21 13:17 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 [this message]
2011-09-21 13:17       ` Michal Nazarewicz
2011-09-21 13:17       ` Michal Nazarewicz
2011-09-21 14:07       ` Dave Hansen
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=op.v15tv0183l0zgt@mnazarewicz-glaptop \
    --to=mina86@mina86.com \
    --cc=akpm@linux-foundation.org \
    --cc=ankita@in.ibm.com \
    --cc=arnd@arndb.de \
    --cc=chunsang.jeong@linaro.org \
    --cc=corbet@lwn.net \
    --cc=dave@linux.vnet.ibm.com \
    --cc=dwalker@codeaurora.org \
    --cc=jesse.barker@linaro.org \
    --cc=kamezawa.hiroyu@jp.fujitsu.com \
    --cc=kyungmin.park@samsung.com \
    --cc=linaro-mm-sig@lists.linaro.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-media@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=linux@arm.linux.org.uk \
    --cc=m.szyprowski@samsung.com \
    --cc=mel@csn.ul.ie \
    --cc=shariq.hasnain@linaro.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.