Linux MIPS Architecture development
 help / color / mirror / Atom feed
From: Ralf Baechle <ralf@linux-mips.org>
To: Franck Bui-Huu <vagabon.xyz@gmail.com>
Cc: linux-mips@linux-mips.org, Franck Bui-Huu <fbuihuu@gmail.com>
Subject: Re: [PATCH 2/3] Setup min_low_pfn/max_low_pfn correctly
Date: Mon, 11 Dec 2006 18:16:40 +0000	[thread overview]
Message-ID: <20061211181640.GA25769@linux-mips.org> (raw)
In-Reply-To: <11654201103291-git-send-email-fbuihuu@gmail.com>

On Wed, Dec 06, 2006 at 04:48:29PM +0100, Franck Bui-Huu wrote:

> The old code was assuming that min_low_pfn was always 0. This
> means that we can't handle platforms with a big hole at start
> of memory since mem_map[] size would blew up.

It was - and IP22 was paying a high price for that.  It's currently 1MB
on 32-bit and 1.75MB on 64-bit kernels - but used to be much higher in
the past.

Btw, I think you're confusing the terms here; your patch description reads
wrong while the patch looks fine.  PFN is page frame number, not physical
frame number.  To avoid wasting dead mem_map[] entries idealy the pfn for
the first allocatable page should be zero.
So ignoring NUMA and discontig memory for a moment (those make everything
more complicated ...) PFN 0 is the first entry in mem_map[] - which usually
but not necessarily is physical address 0x0.

> This patch does not relax this constraint but it's a first
> step to achieve that.

> diff --git a/arch/mips/kernel/setup.c b/arch/mips/kernel/setup.c
> index 89440a0..8e58d7f 100644
> --- a/arch/mips/kernel/setup.c
> +++ b/arch/mips/kernel/setup.c
> @@ -271,7 +271,6 @@ static void __init bootmem_init(void)
>  static void __init bootmem_init(void)
>  {
>  	unsigned long reserved_end;
> -	unsigned long highest = 0;
>  	unsigned long mapstart = -1UL;

Assigning a negative number to an unsigned long variable ...

>  	unsigned long bootmap_size;
>  	int i;
> @@ -284,6 +283,13 @@ static void __init bootmem_init(void)
>  	reserved_end = max(init_initrd(), PFN_UP(__pa_symbol(&_end)));
>  
>  	/*
> +	 * max_low_pfn is not a number of pages. The number of pages
> +	 * of the system is given by 'max_low_pfn - min_low_pfn'.
> +	 */
> +	min_low_pfn = -1UL;

Assigning a negative number to an unsigned long variable ...

  Ralf

  reply	other threads:[~2006-12-11 18:16 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-12-06 15:48 [RFC] FLATMEM: allow memory to start at pfn != 0 Franck Bui-Huu
2006-12-06 15:48 ` [PATCH 1/3] paging_init(): use highend_pfn/highstart_pfn Franck Bui-Huu
2006-12-06 15:48 ` [PATCH 2/3] Setup min_low_pfn/max_low_pfn correctly Franck Bui-Huu
2006-12-11 18:16   ` Ralf Baechle [this message]
2006-12-12  9:14     ` Franck Bui-Huu
2006-12-06 15:48 ` [PATCH 3/3] FLATMEM: allow memory to start at pfn != 0 Franck Bui-Huu
2006-12-11 18:46 ` [RFC] " Ralf Baechle
2006-12-12  8:55   ` Franck Bui-Huu
2006-12-16 11:17   ` Franck Bui-Huu

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=20061211181640.GA25769@linux-mips.org \
    --to=ralf@linux-mips.org \
    --cc=fbuihuu@gmail.com \
    --cc=linux-mips@linux-mips.org \
    --cc=vagabon.xyz@gmail.com \
    /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