From: mina86@mina86.com (Michal Nazarewicz)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH] arm64: fix MAX_ORDER for 64K pagesize
Date: Thu, 19 Jun 2014 21:24:04 +0200 [thread overview]
Message-ID: <xa1tfvj01z57.fsf@mina86.com> (raw)
In-Reply-To: <1403201524.32688.62.camel@deneb.redhat.com>
On Thu, Jun 19 2014, Mark Salter <msalter@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 +--<mpn@google.com>--<xmpp:mina86@jabber.org>--ooO--(_)--Ooo--
WARNING: multiple messages have this Message-ID (diff)
From: Michal Nazarewicz <mina86@mina86.com>
To: Mark Salter <msalter@redhat.com>
Cc: David Rientjes <rientjes@google.com>,
Marek Szyprowski <m.szyprowski@samsung.com>,
Catalin Marinas <catalin.marinas@arm.com>,
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH] arm64: fix MAX_ORDER for 64K pagesize
Date: Thu, 19 Jun 2014 21:24:04 +0200 [thread overview]
Message-ID: <xa1tfvj01z57.fsf@mina86.com> (raw)
In-Reply-To: <1403201524.32688.62.camel@deneb.redhat.com>
On Thu, Jun 19 2014, Mark Salter <msalter@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 +--<mpn@google.com>--<xmpp:mina86@jabber.org>--ooO--(_)--Ooo--
next prev parent reply other threads:[~2014-06-19 19:24 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-06-11 21:33 [PATCH] arm64: fix MAX_ORDER for 64K pagesize Mark Salter
2014-06-11 21:33 ` Mark Salter
2014-06-11 23:03 ` David Rientjes
2014-06-11 23:03 ` David Rientjes
2014-06-11 23:04 ` David Rientjes
2014-06-11 23:04 ` David Rientjes
2014-06-12 13:57 ` Mark Salter
2014-06-12 13:57 ` Mark Salter
2014-06-17 18:32 ` Michal Nazarewicz
2014-06-17 18:32 ` Michal Nazarewicz
2014-06-19 18:12 ` Mark Salter
2014-06-19 18:12 ` Mark Salter
2014-06-19 19:24 ` Michal Nazarewicz [this message]
2014-06-19 19:24 ` Michal Nazarewicz
2014-06-20 17:37 ` Mark Salter
2014-06-20 17:37 ` Mark Salter
2014-06-23 19:40 ` [PATCHv3] mm: page_alloc: fix CMA area initialisation when pageblock > MAX_ORDER Michal Nazarewicz
2014-06-23 19:40 ` Michal Nazarewicz
2014-06-23 21:10 ` Mark Salter
2014-06-23 21:10 ` Mark Salter
2014-06-19 19:53 ` [PATCHv2] " Michal Nazarewicz
2014-06-19 19:53 ` Michal Nazarewicz
2014-06-20 13:54 ` Christopher Covington
2014-06-20 13:54 ` Christopher Covington
2014-06-20 15:48 ` Mark Salter
2014-06-20 15:48 ` Mark Salter
2014-06-20 16:36 ` Michal Nazarewicz
2014-06-20 16:36 ` Michal Nazarewicz
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=xa1tfvj01z57.fsf@mina86.com \
--to=mina86@mina86.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.