lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Thu, 21 Nov 2013 18:25:24 -0700
From:	jerry.hoemann@...com
To:	"H. Peter Anvin" <hpa@...or.com>
Cc:	Matthew Garrett <mjg59@...f.ucam.org>, rob@...dley.net,
	tglx@...utronix.de, mingo@...hat.com, x86@...nel.org,
	matt.fleming@...el.com, yinghai@...nel.org,
	akpm@...ux-foundation.org, bp@...e.de, linux-doc@...r.kernel.org,
	linux-kernel@...r.kernel.org, linux-efi@...r.kernel.org,
	penberg@...nel.org, mingo.kernel.org@...il.com, vgoyal@...hat.com
Subject: Re: [RFC v2 0/2] Early use of boot service memory

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@...com
----------------------------------------------------------------------------

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists