On Thu, Jun 19 2014, Mark Salter <msal...@redhat.com> wrote:
> On Tue, 2014-06-17 at 20:32 +0200, Michal Nazarewicz wrote:
>> diff --git a/mm/page_alloc.c b/mm/page_alloc.c
>> index 5dba293..6e657ce 100644
>> --- a/mm/page_alloc.c
>> +++ b/mm/page_alloc.c
>> @@ -801,7 +801,15 @@ void __init init_cma_reserved_pageblock(struct page
>> *page)
>>
>> set_page_refcounted(page);
>> set_pageblock_migratetype(page, MIGRATE_CMA);
>> - __free_pages(page, pageblock_order);
>> + if (pageblock_order > MAX_ORDER) {
>> + struct page *subpage = p;
>> + unsigned count = 1 << (pageblock_order - MAX_ORDER);
>> + do {
>> + __free_pages(subpage, pageblock_order);
> ^^^^^^^
> MAX_ORDER
D'oh! I'll send a revised patch.
>> + } while (subpage += MAX_ORDER_NR_PAGES, --count);
>> + } else {
>> + __free_pages(page, pageblock_order);
>> + }
>> adjust_managed_page_count(page, pageblock_nr_pages);
>> }
>> #endif
>> --------- >8 ---------------------------------------------------------
>>
>> Thoughts? This has not been tested and I think it may cause performance
>> degradation in some cases since pageblock_order is not always
>> a constant, so the comparison may end up not being stripped away even on
>> systems where it's always false.
> This works with the above tweak. So it fixes the problm here, but I was
> not sure if we'd get bitten elsewhere by pageblock_order > MAX_ORDER.
This is always a possibility, but in such cases, it's a bug in CMA.
I've tried to keep in mind that pageblock_order may be greater than
MAX_ORDER when writing CMA, but I've never tested on such a system.
> It will be slower, but does it only gets called a few time at most at
> boot time, right?
Yes. The performance degradation should be negligible since
init_cma_reserved is hardly a critical path and is called at most
MAX_CMA_AREAS times which by default is 8. And I mean it will be slower
because it will have to perform a branch.
--
Best regards, _ _
.o. | Liege of Serenely Enlightened Majesty of o' \,=./ `o
..o | Computer Science, Michał “mina86” Nazarewicz (o o)
ooo +--<m...@google.com>--<xmpp:min...@jabber.org>--ooO--(_)--Ooo--
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
