All of lore.kernel.org
 help / color / mirror / Atom feed
From: "H. Peter Anvin" <hpa@zytor.com>
To: Yinghai Lu <yinghai@kernel.org>
Cc: zhenzhong.duan@oracle.com, Takashi Iwai <tiwai@suse.de>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	"Rafael J. Wysocki" <rjw@sisk.pl>,
	stable@vger.kernel.org, linux-kernel@vger.kernel.org,
	konrad.wilk@oracle.com, joe.jin@oracle.com,
	Thomas Gleixner <tglx@linutronix.de>,
	Ingo Molnar <mingo@redhat.com>
Subject: Re: [PATCH] Initialize max_pfn_mapped as initial ident mapping size for x86_64
Date: Mon, 05 Mar 2012 17:49:49 -0800	[thread overview]
Message-ID: <4F556D3D.8040400@zytor.com> (raw)
In-Reply-To: <CAE9FiQV3CyB1YRPDxFu-jGr73+Qwpkn4O4QYYZvBJcyZA5Gouw@mail.gmail.com>

On 03/05/2012 05:35 PM, Yinghai Lu wrote:
> 
> whole history:
> before following patch, on x86_64, for low memory (under 4g) pgtable
> will be allocated just under TOML
> and even those memory is not mapped directly. because now we are using
> early_ioremap to access those
> page table.
> 
> but looks it has problem with S4 resume. so good_end is set to initial
> mapped high address.
> (that is 512M). So page table will just below 512M
> but crash kernel is allocated below 768M. so will have no chance to
> get 512M porting for crashkernel.
> 
> Now your patch just set initial mapping limit to 1g. but according to
> arch/x86/kernel/head_64.S
> we only have initial mapping to 512M.
> 
> So you can not just simply set to 1G,  that will confuse early
> memblock allocator.
> 
> We may update find_early_table_space() to use 1G as good_end for
> x86_64 that will be less confusing.
> 

This is crazy.  All of it.  We shouldn't have a bunch of magic memory
limits on 64 bits, and trying to add and subtract to them really just
makes the pain worse.

WHY does it have a problem with S4 resume?  S4 is Linux code, so there
is a bug here that people keep trying to hack around instead of digging
into.

The early mapping range we can fix, and probably should.  Mapping the
first 4 GiB is not a lot of memory and makes a much more sensible
starting point.

	-hpa


-- 
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel.  I don't speak on their behalf.


  reply	other threads:[~2012-03-06  1:50 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <1330669703-20176-1-git-send-email-zhenzhong.duan@oracle.com>
2012-03-06  1:35 ` [PATCH] Initialize max_pfn_mapped as initial ident mapping size for x86_64 Yinghai Lu
2012-03-06  1:49   ` H. Peter Anvin [this message]
2012-03-06  6:27     ` Yinghai Lu
2012-03-06  6:27       ` Yinghai Lu
2012-03-06  7:00       ` H. Peter Anvin

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=4F556D3D.8040400@zytor.com \
    --to=hpa@zytor.com \
    --cc=joe.jin@oracle.com \
    --cc=konrad.wilk@oracle.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@redhat.com \
    --cc=rjw@sisk.pl \
    --cc=stable@vger.kernel.org \
    --cc=tglx@linutronix.de \
    --cc=tiwai@suse.de \
    --cc=torvalds@linux-foundation.org \
    --cc=yinghai@kernel.org \
    --cc=zhenzhong.duan@oracle.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 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.