All of lore.kernel.org
 help / color / mirror / Atom feed
From: will.deacon@arm.com (Will Deacon)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 1/2] arm64: mem-model: add flatmem model for arm64
Date: Mon, 11 Apr 2016 11:40:13 +0100	[thread overview]
Message-ID: <20160411104013.GG15729@arm.com> (raw)
In-Reply-To: <CAKv+Gu-cWWUi6fCiveqaZRVhGCpEasCLEs7wq6t+C-x65g4cgQ@mail.gmail.com>

On Mon, Apr 11, 2016 at 12:31:53PM +0200, Ard Biesheuvel wrote:
> On 11 April 2016 at 11:59, Chen Feng <puck.chen@hisilicon.com> wrote:
> > Please see the pg-tables below.
> >
> >
> > With sparse and vmemmap enable.
> >
> > ---[ vmemmap start ]---
> > 0xffffffbdc0200000-0xffffffbdc4800000          70M     RW NX SHD AF    UXN MEM/NORMAL
> > ---[ vmemmap end ]---
> >
> 
> OK, I see what you mean now. Sorry for taking so long to catch up.
> 
> > The board is 4GB, and the memap is 70MB
> > 1G memory --- 14MB mem_map array.
> 
> No, this is incorrect. 1 GB corresponds with 16 MB worth of struct
> pages assuming sizeof(struct page) == 64
> 
> So you are losing 6 MB to rounding here, which I agree is significant.
> I wonder if it makes sense to use a lower value for SECTION_SIZE_BITS
> on 4k pages kernels, but perhaps we're better off asking the opinion
> of the other cc'ees.

You need to be really careful making SECTION_SIZE_BITS smaller because
it has a direct correlation on the use of page->flags and you can end up
running out of bits fairly easily.

Will

WARNING: multiple messages have this Message-ID (diff)
From: Will Deacon <will.deacon@arm.com>
To: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Chen Feng <puck.chen@hisilicon.com>,
	Mark Rutland <mark.rutland@arm.com>,
	mhocko@suse.com, Laura Abbott <labbott@redhat.com>,
	Dan Zhao <dan.zhao@hisilicon.com>,
	Yiping Xu <xuyiping@hisilicon.com>,
	puck.chen@foxmail.com, albert.lubing@hisilicon.com,
	Catalin Marinas <catalin.marinas@arm.com>,
	suzhuangluan@hisilicon.com,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	linuxarm@huawei.com, "linux-mm@kvack.org" <linux-mm@kvack.org>,
	kirill.shutemov@linux.intel.com,
	David Rientjes <rientjes@google.com>,
	oliver.fu@hisilicon.com,
	Andrew Morton <akpm@linux-foundation.org>,
	robin.murphy@arm.com,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>,
	saberlily.xia@hisilicon.com
Subject: Re: [PATCH 1/2] arm64: mem-model: add flatmem model for arm64
Date: Mon, 11 Apr 2016 11:40:13 +0100	[thread overview]
Message-ID: <20160411104013.GG15729@arm.com> (raw)
In-Reply-To: <CAKv+Gu-cWWUi6fCiveqaZRVhGCpEasCLEs7wq6t+C-x65g4cgQ@mail.gmail.com>

On Mon, Apr 11, 2016 at 12:31:53PM +0200, Ard Biesheuvel wrote:
> On 11 April 2016 at 11:59, Chen Feng <puck.chen@hisilicon.com> wrote:
> > Please see the pg-tables below.
> >
> >
> > With sparse and vmemmap enable.
> >
> > ---[ vmemmap start ]---
> > 0xffffffbdc0200000-0xffffffbdc4800000          70M     RW NX SHD AF    UXN MEM/NORMAL
> > ---[ vmemmap end ]---
> >
> 
> OK, I see what you mean now. Sorry for taking so long to catch up.
> 
> > The board is 4GB, and the memap is 70MB
> > 1G memory --- 14MB mem_map array.
> 
> No, this is incorrect. 1 GB corresponds with 16 MB worth of struct
> pages assuming sizeof(struct page) == 64
> 
> So you are losing 6 MB to rounding here, which I agree is significant.
> I wonder if it makes sense to use a lower value for SECTION_SIZE_BITS
> on 4k pages kernels, but perhaps we're better off asking the opinion
> of the other cc'ees.

You need to be really careful making SECTION_SIZE_BITS smaller because
it has a direct correlation on the use of page->flags and you can end up
running out of bits fairly easily.

Will

--
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/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

WARNING: multiple messages have this Message-ID (diff)
From: Will Deacon <will.deacon@arm.com>
To: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Chen Feng <puck.chen@hisilicon.com>,
	Mark Rutland <mark.rutland@arm.com>,
	mhocko@suse.com, Laura Abbott <labbott@redhat.com>,
	Dan Zhao <dan.zhao@hisilicon.com>,
	Yiping Xu <xuyiping@hisilicon.com>,
	puck.chen@foxmail.com, albert.lubing@hisilicon.com,
	Catalin Marinas <catalin.marinas@arm.com>,
	suzhuangluan@hisilicon.com,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	linuxarm@huawei.com, "linux-mm@kvack.org" <linux-mm@kvack.org>,
	kirill.shutemov@linux.intel.com,
	David Rientjes <rientjes@google.com>,
	oliver.fu@hisilicon.com,
	Andrew Morton <akpm@linux-foundation.org>,
	robin.murphy@arm.com,
	"linux-arm-kernel@lists.infradead.org" 
	<linux-arm-kernel@lists.infradead.org>,
	saberlily.xia@hisilicon.com
Subject: Re: [PATCH 1/2] arm64: mem-model: add flatmem model for arm64
Date: Mon, 11 Apr 2016 11:40:13 +0100	[thread overview]
Message-ID: <20160411104013.GG15729@arm.com> (raw)
In-Reply-To: <CAKv+Gu-cWWUi6fCiveqaZRVhGCpEasCLEs7wq6t+C-x65g4cgQ@mail.gmail.com>

On Mon, Apr 11, 2016 at 12:31:53PM +0200, Ard Biesheuvel wrote:
> On 11 April 2016 at 11:59, Chen Feng <puck.chen@hisilicon.com> wrote:
> > Please see the pg-tables below.
> >
> >
> > With sparse and vmemmap enable.
> >
> > ---[ vmemmap start ]---
> > 0xffffffbdc0200000-0xffffffbdc4800000          70M     RW NX SHD AF    UXN MEM/NORMAL
> > ---[ vmemmap end ]---
> >
> 
> OK, I see what you mean now. Sorry for taking so long to catch up.
> 
> > The board is 4GB, and the memap is 70MB
> > 1G memory --- 14MB mem_map array.
> 
> No, this is incorrect. 1 GB corresponds with 16 MB worth of struct
> pages assuming sizeof(struct page) == 64
> 
> So you are losing 6 MB to rounding here, which I agree is significant.
> I wonder if it makes sense to use a lower value for SECTION_SIZE_BITS
> on 4k pages kernels, but perhaps we're better off asking the opinion
> of the other cc'ees.

You need to be really careful making SECTION_SIZE_BITS smaller because
it has a direct correlation on the use of page->flags and you can end up
running out of bits fairly easily.

Will

  reply	other threads:[~2016-04-11 10:40 UTC|newest]

Thread overview: 69+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-04-05  8:22 [PATCH 1/2] arm64: mem-model: add flatmem model for arm64 Chen Feng
2016-04-05  8:22 ` Chen Feng
2016-04-05  8:22 ` Chen Feng
2016-04-05  8:22 ` [PATCH 2/2] arm64: mm: make pfn always valid with flat memory Chen Feng
2016-04-05  8:22   ` Chen Feng
2016-04-05  8:22   ` Chen Feng
2016-04-07  7:39   ` Chen Feng
2016-04-07  7:39     ` Chen Feng
2016-04-07  7:39     ` Chen Feng
2016-04-11 11:08   ` Xishi Qiu
2016-04-11 11:08     ` Xishi Qiu
2016-04-11 11:08     ` Xishi Qiu
2016-04-12 15:00     ` Catalin Marinas
2016-04-12 15:00       ` Catalin Marinas
2016-04-12 15:00       ` Catalin Marinas
2016-04-07  7:38 ` [PATCH 1/2] arm64: mem-model: add flatmem model for arm64 Chen Feng
2016-04-07  7:38   ` Chen Feng
2016-04-07  7:38   ` Chen Feng
2016-04-07 14:21 ` Will Deacon
2016-04-07 14:21   ` Will Deacon
2016-04-07 14:21   ` Will Deacon
2016-04-11  2:49   ` Chen Feng
2016-04-11  2:49     ` Chen Feng
2016-04-11  2:49     ` Chen Feng
2016-04-11  7:35     ` Ard Biesheuvel
2016-04-11  7:35       ` Ard Biesheuvel
2016-04-11  7:35       ` Ard Biesheuvel
2016-04-11  7:55       ` Chen Feng
2016-04-11  7:55         ` Chen Feng
2016-04-11  7:55         ` Chen Feng
2016-04-11  8:00         ` Ard Biesheuvel
2016-04-11  8:00           ` Ard Biesheuvel
2016-04-11  8:00           ` Ard Biesheuvel
2016-04-11  9:59           ` Chen Feng
2016-04-11  9:59             ` Chen Feng
2016-04-11  9:59             ` Chen Feng
2016-04-11 10:31             ` Ard Biesheuvel
2016-04-11 10:31               ` Ard Biesheuvel
2016-04-11 10:31               ` Ard Biesheuvel
2016-04-11 10:40               ` Will Deacon [this message]
2016-04-11 10:40                 ` Will Deacon
2016-04-11 10:40                 ` Will Deacon
2016-04-11 10:57                 ` Chen Feng
2016-04-11 10:57                   ` Chen Feng
2016-04-11 10:57                   ` Chen Feng
2016-04-11 18:11                   ` Laura Abbott
2016-04-11 18:11                     ` Laura Abbott
2016-04-11 18:11                     ` Laura Abbott
2016-04-12 14:44                 ` Catalin Marinas
2016-04-12 14:44                   ` Catalin Marinas
2016-04-12 14:44                   ` Catalin Marinas
2016-04-12 14:59               ` Catalin Marinas
2016-04-12 14:59                 ` Catalin Marinas
2016-04-12 14:59                 ` Catalin Marinas
2016-04-20  3:18                 ` Chen Feng
2016-04-20  3:18                   ` Chen Feng
2016-04-20  3:18                   ` Chen Feng
2016-04-20  9:32                   ` Catalin Marinas
2016-04-20  9:32                     ` Catalin Marinas
2016-04-20  9:32                     ` Catalin Marinas
2016-04-11 10:48             ` Chen Feng
2016-04-11 10:48               ` Chen Feng
2016-04-11 10:48               ` Chen Feng
2016-04-11 11:02               ` Ard Biesheuvel
2016-04-11 11:02                 ` Ard Biesheuvel
2016-04-11 11:02                 ` Ard Biesheuvel
2016-04-12 14:03     ` Jungseok Lee
2016-04-12 14:03       ` Jungseok Lee
2016-04-12 14:03       ` Jungseok Lee

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=20160411104013.GG15729@arm.com \
    --to=will.deacon@arm.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.