linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: "Michal Nazarewicz" <mina86@mina86.com>
To: Marek Szyprowski <m.szyprowski@samsung.com>, Mel Gorman <mel@csn.ul.ie>
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>,
	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>,
	Dave Hansen <dave@linux.vnet.ibm.com>
Subject: Re: [PATCH 2/9] mm: alloc_contig_freed_pages() added
Date: Tue, 18 Oct 2011 10:26:37 -0700	[thread overview]
Message-ID: <op.v3j5ent03l0zgt@mpn-glaptop> (raw)
In-Reply-To: <20111018122109.GB6660@csn.ul.ie>

On Tue, 18 Oct 2011 05:21:09 -0700, Mel Gorman <mel@csn.ul.ie> wrote:

> At this point, I'm going to apologise for not reviewing this a long long
> time ago.
>
> On Thu, Oct 06, 2011 at 03:54:42PM +0200, Marek Szyprowski wrote:
>> From: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
>>
>> This commit introduces alloc_contig_freed_pages() function
>> which allocates (ie. removes from buddy system) free pages
>> in range. Caller has to guarantee that all pages in range
>> are in buddy system.
>>
>
> Straight away, I'm wondering why you didn't use
>
> mm/compaction.c#isolate_freepages()
>
> It knows how to isolate pages within ranges. All its control information
> is passed via struct compact_control() which I recognise may be awkward
> for CMA but compaction.c know how to manage all the isolated pages and
> pass them to migrate.c appropriately.

It is something to consider.  At first glance, I see that isolate_freepages
seem to operate on pageblocks which is not desired for CMA.

> I haven't read all the patches yet but isolate_freepages() does break
> everything up into order-0 pages. This may not be to your liking but it
> would not be possible to change.

Splitting everything into order-0 pages is desired behaviour.

>> Along with this function, a free_contig_pages() function is
>> provided which frees all (or a subset of) pages allocated
>> with alloc_contig_free_pages().

> mm/compaction.c#release_freepages()

It sort of does the same thing but release_freepages() assumes that pages
that are being freed are not-continuous and they need to be on the lru list.
With free_contig_pages(), we can assume all pages are continuous.

>> +#if defined(CONFIG_SPARSEMEM) && !defined(CONFIG_SPARSEMEM_VMEMMAP)
>> +/*
>> + * Both PFNs must be from the same zone!  If this function returns
>> + * true, pfn_to_page(pfn1) + (pfn2 - pfn1) == pfn_to_page(pfn2).
>> + */
>> +static inline bool zone_pfn_same_memmap(unsigned long pfn1, unsigned long pfn2)
>> +{
>> +	return pfn_to_section_nr(pfn1) == pfn_to_section_nr(pfn2);
>> +}
>> +
>
> Why do you care what section the page is in? The zone is important all
> right, but not the section. Also, offhand I'm unsure if being in the
> same section guarantees the same zone. sections are ordinarily fully
> populated (except on ARM but hey) but I can't remember anything
> enforcing that zones be section-aligned.
>
> Later I think I see that the intention was to reduce the use of
> pfn_to_page().

That is correct.

> You can do this in a more general fashion by checking the
> zone boundaries and resolving the pfn->page every MAX_ORDER_NR_PAGES.
> That will not be SPARSEMEM specific.

I've tried doing stuff that way but it ended up with much more code.

Dave suggested the above function to check if pointer arithmetic is valid.

Please see also <https://lkml.org/lkml/2011/9/21/220>.

>
>> +#else
>> +
>> +#define zone_pfn_same_memmap(pfn1, pfn2) (true)
>> +
>> +#endif
>> +
>>  #endif /* !__GENERATING_BOUNDS.H */
>>  #endif /* !__ASSEMBLY__ */
>>  #endif /* _LINUX_MMZONE_H */


>> @@ -5706,6 +5706,73 @@ out:
>>  	spin_unlock_irqrestore(&zone->lock, flags);
>>  }
>>
>> +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));
>
> VM_BUG_ON seems very harsh here. WARN_ON_ONCE and returning 0 to the
> caller sees reasonable.
>
>> +	page = pfn_to_page(start);
>> +	zone = page_zone(page);
>> +
>> +	spin_lock_irq(&zone->lock);
>> +
>> +	for (;;) {
>> +		VM_BUG_ON(page_count(page) || !PageBuddy(page) ||
>> +			  page_zone(page) != zone);
>> +
>
> Here you will VM_BUG_ON with the zone lock held leading to system
> halting very shortly.
>
>> +		list_del(&page->lru);
>> +		order = page_order(page);
>> +		count = 1UL << order;
>> +		zone->free_area[order].nr_free--;
>> +		rmv_page_order(page);
>> +		__mod_zone_page_state(zone, NR_FREE_PAGES, -(long)count);
>> +
>
> The callers need to check in advance if watermarks are sufficient for
> this. In compaction, it happens in compaction_suitable() because it only
> needed to be checked once. Your requirements might be different.
>
>> +		pfn += count;
>> +		if (pfn >= end)
>> +			break;
>> +		VM_BUG_ON(!pfn_valid(pfn));
>> +
>
> On ARM, it's possible to encounter invalid pages. VM_BUG_ON is serious
> overkill.
>
>> +		if (zone_pfn_same_memmap(pfn - count, pfn))
>> +			page += count;
>> +		else
>> +			page = pfn_to_page(pfn);
>> +	}
>> +
>> +	spin_unlock_irq(&zone->lock);
>> +
>> +	/* After this, pages in the range can be freed one be one */
>> +	count = pfn - start;
>> +	pfn = start;
>> +	for (page = pfn_to_page(pfn); count; --count) {
>> +		prep_new_page(page, 0, flag);
>> +		++pfn;
>> +		if (likely(zone_pfn_same_memmap(pfn - 1, pfn)))
>> +			++page;
>> +		else
>> +			page = pfn_to_page(pfn);
>> +	}
>> +
>
> Here it looks like you have implemented something like split_free_page().

split_free_page() takes a single page, removes it from buddy system, and finally
splits it.  alloc_contig_freed_pages() takes a range of pages, removes them from
buddy system, and finally splits them.  Because it works on a range, it is
made into a separate function.

>> +	return pfn;
>> +}

-- 
Best regards,                                         _     _
.o. | Liege of Serenely Enlightened Majesty of      o' \,=./ `o
..o | Computer Science,  Michał “mina86” Nazarewicz    (o o)
ooo +----<email/xmpp: mpn@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>

  reply	other threads:[~2011-10-18 17:26 UTC|newest]

Thread overview: 64+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-10-06 13:54 [PATCHv16 0/9] Contiguous Memory Allocator Marek Szyprowski
2011-10-06 13:54 ` [PATCH 1/9] mm: move some functions from memory_hotplug.c to page_isolation.c Marek Szyprowski
2011-10-14 23:23   ` Andrew Morton
2011-10-18 12:05   ` Mel Gorman
2011-10-06 13:54 ` [PATCH 2/9] mm: alloc_contig_freed_pages() added Marek Szyprowski
2011-10-14 23:29   ` Andrew Morton
2011-10-16  8:01     ` Michal Nazarewicz
2011-10-16  8:31       ` Andrew Morton
2011-10-16  9:39         ` Michal Nazarewicz
2011-10-17 12:21     ` Marek Szyprowski
2011-10-17 18:39       ` Andrew Morton
2011-10-18 12:21   ` Mel Gorman
2011-10-18 17:26     ` Michal Nazarewicz [this message]
2011-10-18 17:48       ` Dave Hansen
2011-10-18 18:00         ` Michal Nazarewicz
2011-10-21 10:06       ` Mel Gorman
2011-10-24  1:00         ` Michal Nazarewicz
2011-10-24  4:05     ` Michal Nazarewicz
2011-11-01 15:04       ` Mel Gorman
2011-11-01 18:06         ` Michal Nazarewicz
2011-11-01 18:47           ` Mel Gorman
2011-10-24  4:05     ` Michal Nazarewicz
2011-10-24  4:05     ` Michal Nazarewicz
2011-10-24  4:05     ` Michal Nazarewicz
2011-10-06 13:54 ` [PATCH 3/9] mm: alloc_contig_range() added Marek Szyprowski
2011-10-14 23:35   ` Andrew Morton
2011-10-18 12:38   ` Mel Gorman
2011-10-06 13:54 ` [PATCH 4/9] mm: MIGRATE_CMA migration type added Marek Szyprowski
2011-10-14 23:38   ` Andrew Morton
2011-10-18 13:08   ` Mel Gorman
2011-10-24 19:32     ` Michal Nazarewicz
2011-10-27  9:10       ` Michal Nazarewicz
2011-10-06 13:54 ` [PATCH 5/9] mm: MIGRATE_CMA isolation functions added Marek Szyprowski
2011-10-06 13:54 ` [PATCH 6/9] drivers: add Contiguous Memory Allocator Marek Szyprowski
2011-10-14 23:57   ` Andrew Morton
2011-10-16 10:08     ` Russell King - ARM Linux
2011-10-18 13:43   ` Mel Gorman
2011-10-24 19:39     ` Michal Nazarewicz
2011-11-04 10:41     ` Marek Szyprowski
2011-10-06 13:54 ` [PATCH 7/7] ARM: integrate CMA with DMA-mapping subsystem Marek Szyprowski
2011-10-06 14:18   ` Marek Szyprowski
2011-10-15  0:03   ` Andrew Morton
2011-10-06 13:54 ` [PATCH 7/9] X86: " Marek Szyprowski
2011-10-06 13:54 ` [PATCH 8/9] ARM: " Marek Szyprowski
2011-10-14  4:33   ` [Linaro-mm-sig] " Subash Patel
2011-10-14  9:14     ` Marek Szyprowski
2011-10-06 13:54 ` [PATCH 9/9] ARM: Samsung: use CMA for 2 memory banks for s5p-mfc device Marek Szyprowski
2011-10-07 16:27 ` [PATCHv16 0/9] Contiguous Memory Allocator Arnd Bergmann
2011-10-10  6:58   ` [Linaro-mm-sig] " Ohad Ben-Cohen
2011-10-10 12:02     ` Clark, Rob
2011-10-10 22:56   ` Andrew Morton
2011-10-11  6:57     ` Marek Szyprowski
2011-10-11 13:52     ` Arnd Bergmann
2011-10-14 23:19       ` Andrew Morton
2011-10-15 14:24         ` Arnd Bergmann
2011-10-10 12:07 ` [Linaro-mm-sig] " Maxime Coquelin
2011-10-11  7:17   ` Marek Szyprowski
2011-10-11  7:30     ` Maxime Coquelin
2011-10-11 10:50       ` Marek Szyprowski
2011-10-11 11:25         ` Maxime Coquelin
2011-10-11 13:05           ` Marek Szyprowski
2011-10-12 11:08       ` [PATCH] fixup: mm: alloc_contig_range: increase min_free_kbytes during allocation Marek Szyprowski
2011-10-12 13:01         ` Maxime Coquelin
  -- strict thread matches above, loose matches on Subject: below --
2011-08-12 10:58 [PATCHv14 0/9] Contiguous Memory Allocator Marek Szyprowski
2011-08-12 10:58 ` [PATCH 2/9] mm: alloc_contig_freed_pages() added Marek Szyprowski

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.v3j5ent03l0zgt@mpn-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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox