All of lore.kernel.org
 help / color / mirror / Atom feed
From: Vivek Goyal <vgoyal@in.ibm.com>
To: Magnus Damm <magnus.damm@gmail.com>
Cc: Mel Gorman <mel@csn.ul.ie>, Magnus Damm <magnus@valinux.co.jp>,
	linux-kernel@vger.kernel.org, Andi Kleen <ak@muc.de>,
	fastboot@lists.osdl.org
Subject: Re: [PATCH] x86_64: setup saved_max_pfn correctly (kdump)
Date: Thu, 2 Nov 2006 13:20:11 -0500	[thread overview]
Message-ID: <20061102182011.GE8074@in.ibm.com> (raw)
In-Reply-To: <aec7e5c30611021005y2f26319ei1c61963d354a933f@mail.gmail.com>

On Fri, Nov 03, 2006 at 03:05:08AM +0900, Magnus Damm wrote:
> Hi Mel,
> 
> Thanks for your input! Great work with the add_active_range() code.
> 
> On 11/3/06, Mel Gorman <mel@csn.ul.ie> wrote:
> >Hey Magnus,
> >
> >I see what you are doing and why. However if you look in
> >arch/x86_64/kernel/setup.c, you'll see
> >
> >         parse_early_param();
> >
> >         finish_e820_parsing();
> >
> >         e820_register_active_regions(0, 0, -1UL);
> >
> >If you just called e820_register_active_regions(0, 0, -1UL) before
> >parse_early_param(), would it still fix the problem without having to call
> >e820_register_active_regions(0, 0, -1UL) twice?
> 
> Well, I guess it is possible to move the
> e820_register_active_regions() up, but I'm not sure if that would give
> us anything.
> 
> We need to call e820_register_active_regions() before e820_end_of_ram,
> that's for sure, but the "exactmap" code in parse_memmap_opt() sets
> e820.nr_map to 0 after the call to e820_end_of_ram(). Then it adds a
> new set of user-supplied ranges to the e820 map which then need to be
> registered using e820_register_active_regions().
> 
> So yeah, we can move the function up above parse_early_param() but
> then we need to insert another call to e820_register_active_regions()
> somewhere after all user-supplied ranges have been added.
> 
> Another solution could be to rewrite e820_end_of_ram() to instead scan
> e820.map[] backwards from e820.nr_map - 1 to locate the last ram page.
> But can you do that in two lines of code? =)
> 

Is there are reason that why e820_end_of_ram() should be looking at active
regions instead of dicrectly probing e820 memory map? If no, then modifying
e820_end_of_ram() wil save us extra calls.

Thanks
Vivek

  reply	other threads:[~2006-11-02 18:20 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-11-02 13:19 [PATCH] x86_64: setup saved_max_pfn correctly (kdump) Magnus Damm
2006-11-02 14:28 ` Vivek Goyal
2006-11-02 17:40   ` Magnus Damm
2006-11-02 18:07     ` Vivek Goyal
2006-11-02 16:08 ` Mel Gorman
2006-11-02 18:05   ` Magnus Damm
2006-11-02 18:20     ` Vivek Goyal [this message]
2006-11-02 18:28       ` Magnus Damm
2006-11-02 22:41     ` Mel Gorman
2006-11-02 17:40 ` Andi Kleen
2006-11-02 18:20   ` Magnus Damm

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=20061102182011.GE8074@in.ibm.com \
    --to=vgoyal@in.ibm.com \
    --cc=ak@muc.de \
    --cc=fastboot@lists.osdl.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=magnus.damm@gmail.com \
    --cc=magnus@valinux.co.jp \
    --cc=mel@csn.ul.ie \
    /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.