From: jerry.hoemann@hp.com
To: "H. Peter Anvin" <hpa@zytor.com>
Cc: Matthew Garrett <mjg59@srcf.ucam.org>,
rob@landley.net, tglx@linutronix.de, mingo@redhat.com,
x86@kernel.org, matt.fleming@intel.com, yinghai@kernel.org,
akpm@linux-foundation.org, bp@suse.de, linux-doc@vger.kernel.org,
linux-kernel@vger.kernel.org, linux-efi@vger.kernel.org,
penberg@kernel.org, mingo.kernel.org@gmail.com,
vgoyal@redhat.com
Subject: Re: [RFC v2 0/2] Early use of boot service memory
Date: Thu, 21 Nov 2013 18:25:24 -0700 [thread overview]
Message-ID: <20131122012524.GA5627@anatevka.fc.hp.com> (raw)
In-Reply-To: <528EAF99.1010503@zytor.com>
On Thu, Nov 21, 2013 at 05:12:57PM -0800, H. Peter Anvin wrote:
> On 11/21/2013 03:37 PM, Matthew Garrett wrote:
> > On Thu, Nov 21, 2013 at 03:18:41PM -0800, H. Peter Anvin wrote:
> >> On 11/21/2013 03:07 PM, Matthew Garrett wrote:
> >>> This is a problem we have to solve, but I don't think this is the right
> >>> way to solve it. Why do we not just reattempt to perform the allocation
> >>> immediately after we've freed the boot services regions?
> >>>
> >>
> >> Wouldn't the memory map already have gotten scrambled all to hell by then?
> >
> > If we couldn't map a 64MB region in low memory earlier then it's likely
> > to have been because there was a 64MB or greater boot services region.
> >
>
> I thought the problem was that they wanted to map a fairly large chunk
> for faster kdump and fragmentation was being a problem.
>
> -hpa
larger crash dump reservation is not so much performance as functionality.
Large systems w/ lots of IO require large crash kernel allocations for
the kernel to boot. Then you have to worry about the OOM killer.....
makedumpfile going to cyclic buffer has helped out greatly, but on
our new systems we're still looking at 512 MB crash kernels.
--
----------------------------------------------------------------------------
Jerry Hoemann Software Engineer Hewlett-Packard
3404 E Harmony Rd. MS 57 phone: (970) 898-1022
Ft. Collins, CO 80528 FAX: (970) 898-XXXX
email: jerry.hoemann@hp.com
----------------------------------------------------------------------------
next prev parent reply other threads:[~2013-11-22 1:25 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-11-21 21:01 [RFC v2 0/2] Early use of boot service memory Jerry Hoemann
2013-11-21 21:01 ` [RFC v2 1/2] efi: " Jerry Hoemann
2013-11-21 21:01 ` [RFC v2 2/2] x86, " Jerry Hoemann
2013-11-21 22:19 ` Borislav Petkov
2013-11-21 23:07 ` [RFC v2 0/2] " Matthew Garrett
2013-11-21 23:18 ` H. Peter Anvin
2013-11-21 23:37 ` Matthew Garrett
2013-11-22 1:12 ` H. Peter Anvin
2013-11-22 1:25 ` jerry.hoemann [this message]
2013-11-22 1:29 ` Yinghai Lu
2013-11-22 1:31 ` H. Peter Anvin
2013-11-22 2:34 ` Vivek Goyal
2013-11-22 2:42 ` H. Peter Anvin
2013-11-22 2:29 ` Vivek Goyal
2013-11-22 3:32 ` HATAYAMA Daisuke
2013-11-22 2:32 ` Vivek Goyal
2013-11-21 23:31 ` jerry.hoemann
2013-11-21 23:38 ` Matthew Garrett
2013-11-22 1:05 ` jerry.hoemann
2013-11-22 1:16 ` Matthew Garrett
2013-12-16 18:43 ` jerry.hoemann
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=20131122012524.GA5627@anatevka.fc.hp.com \
--to=jerry.hoemann@hp.com \
--cc=akpm@linux-foundation.org \
--cc=bp@suse.de \
--cc=hpa@zytor.com \
--cc=linux-doc@vger.kernel.org \
--cc=linux-efi@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=matt.fleming@intel.com \
--cc=mingo.kernel.org@gmail.com \
--cc=mingo@redhat.com \
--cc=mjg59@srcf.ucam.org \
--cc=penberg@kernel.org \
--cc=rob@landley.net \
--cc=tglx@linutronix.de \
--cc=vgoyal@redhat.com \
--cc=x86@kernel.org \
--cc=yinghai@kernel.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox