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 4/9] mm: MIGRATE_CMA migration type added
Date: Mon, 24 Oct 2011 12:32:45 -0700 [thread overview]
Message-ID: <op.v3ve8vbl3l0zgt@mpn-glaptop> (raw)
In-Reply-To: <20111018130826.GD6660@csn.ul.ie>
> On Thu, Oct 06, 2011 at 03:54:44PM +0200, Marek Szyprowski wrote:
>> The MIGRATE_CMA migration type has two main characteristics:
>> (i) only movable pages can be allocated from MIGRATE_CMA
>> pageblocks and (ii) page allocator will never change migration
>> type of MIGRATE_CMA pageblocks.
>>
>> This guarantees that page in a MIGRATE_CMA page block can
>> always be migrated somewhere else (unless there's no memory left
>> in the system).
On Tue, 18 Oct 2011 06:08:26 -0700, Mel Gorman <mel@csn.ul.ie> wrote:
> Or the count is premanently elevated by a device driver for some reason or if
> the page is backed by a filesystem with a broken or unusable migrate_page()
> function. This is unavoidable, I'm just pointing out that you can stil have
> migration failures, particularly if GFP_MOVABLE has been improperly used.
CMA does not handle that well right now. I guess it's something to think about
once the rest is nice and working.
>> It is designed to be used with Contiguous Memory Allocator
>> (CMA) for allocating big chunks (eg. 10MiB) of physically
>> contiguous memory. Once driver requests contiguous memory,
>> CMA will migrate pages from MIGRATE_CMA pageblocks.
>>
>> To minimise number of migrations, MIGRATE_CMA migration type
>> is the last type tried when page allocator falls back to other
>> migration types then requested.
> It would be preferable if you could figure out how to reuse the
> MIGRATE_RESERVE type for just the bitmap.
I'm not entirely sure of what you mean here.
> Like MIGRATE_CMA, it does not
> change type except when min_free_kbytes changes. However, it is
> something that could be done in the future to keep the size of the
> pageblock bitmap where it is now.
>> +enum {
>> + MIGRATE_UNMOVABLE,
>> + MIGRATE_RECLAIMABLE,
>> + MIGRATE_MOVABLE,
>> + MIGRATE_PCPTYPES, /* the number of types on the pcp lists */
>> + MIGRATE_RESERVE = MIGRATE_PCPTYPES,
>> + /*
>> + * MIGRATE_CMA migration type is designed to mimic the way
>> + * ZONE_MOVABLE works. Only movable pages can be allocated
>> + * from MIGRATE_CMA pageblocks and page allocator never
>> + * implicitly change migration type of MIGRATE_CMA pageblock.
>> + *
>> + * The way to use it is to change migratetype of a range of
>> + * pageblocks to MIGRATE_CMA which can be done by
>> + * __free_pageblock_cma() function. What is important though
>> + * is that a range of pageblocks must be aligned to
>> + * MAX_ORDER_NR_PAGES should biggest page be bigger then
>> + * a single pageblock.
>> + */
>> + MIGRATE_CMA,
> This does mean that MIGRATE_CMA also does not have a per-cpu list.
> I don't know if that matters to you but all allocations using
> MIGRATE_CMA will take the zone lock.
This is sort of an artefact of my misunderstanding of pcp lists in the
past. I'll have to re-evaluate the decision not to include CMA on pcp
list.
Still, I think that CMA not being on pcp lists should not be a problem
for us. At least we can try and get CMA running and then consider adding
CMA to pcp lists.
> I'm not sure this can be easily avoided because
> if there is a per-CPU list for MIGRATE_CMA, it might use a new cache
> line for it and incur a different set of performance problems.
>> + MIGRATE_ISOLATE, /* can't allocate from here */
>> + MIGRATE_TYPES
>> +};
>> diff --git a/mm/compaction.c b/mm/compaction.c
>> index 97254e4..9cf6b2b 100644
>> --- a/mm/compaction.c
>> +++ b/mm/compaction.c
>> @@ -115,6 +115,16 @@ static bool suitable_migration_target(struct page *page)
>> if (migratetype == MIGRATE_ISOLATE || migratetype == MIGRATE_RESERVE)
>> return false;
>>
>> + /* Keep MIGRATE_CMA alone as well. */
>> + /*
>> + * XXX Revisit. We currently cannot let compaction touch CMA
>> + * pages since compaction insists on changing their migration
>> + * type to MIGRATE_MOVABLE (see split_free_page() called from
>> + * isolate_freepages_block() above).
>> + */
>> + if (is_migrate_cma(migratetype))
>> + return false;
>> +
>
> This is another reason why CMA and compaction should be using almost
> identical code. It does mean that the compact_control may need to be
> renamed and get flags to control things like the setting of pageblock
> flags but it would be preferable to having two almost identical pieces
> of code.
I've addressed it in my other mail where I've changed the split_free_page()
to not touch CMA and ISOLATE pageblocks. I think that this change should
make the above comment no longer accurate and the check unnecessary.
>> /* If the page is a large free page, then allow migration */
>> if (PageBuddy(page) && page_order(page) >= pageblock_order)
>> return true;
>> @@ -940,12 +963,12 @@ __rmqueue_fallback(struct zone *zone, int order, int start_migratetype)
>> /* Find the largest possible block of pages in the other list */
>> for (current_order = MAX_ORDER-1; current_order >= order;
>> --current_order) {
>> - for (i = 0; i < MIGRATE_TYPES - 1; i++) {
>> + for (i = 0; i < ARRAY_SIZE(fallbacks[0]); i++) {
>
> I don't see why this change is necessary.
It changes a sort of a magic number into a value that is calculated
from the array. This makes it resistant to changes in the definition
of the fallbacks array. I think this is a reasonable change.
>> migratetype = fallbacks[start_migratetype][i];
>>
>> /* MIGRATE_RESERVE handled later if necessary */
>> if (migratetype == MIGRATE_RESERVE)
>> - continue;
>> + break;
>>
>> area = &(zone->free_area[current_order]);
>> if (list_empty(&area->free_list[migratetype]))
--
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>
next prev parent reply other threads:[~2011-10-24 19:32 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
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-10-24 4:05 ` Michal Nazarewicz
2011-10-24 4:05 ` 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-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 [this message]
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 4/9] mm: MIGRATE_CMA migration type 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.v3ve8vbl3l0zgt@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