From owner-svn-src-all@freebsd.org Fri Oct 9 17:59:12 2015 Return-Path: Delivered-To: svn-src-all@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id C37AA9D174D; Fri, 9 Oct 2015 17:59:12 +0000 (UTC) (envelope-from etnapierala@gmail.com) Received: from mail-wi0-x230.google.com (mail-wi0-x230.google.com [IPv6:2a00:1450:400c:c05::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 58483F02; Fri, 9 Oct 2015 17:59:12 +0000 (UTC) (envelope-from etnapierala@gmail.com) Received: by wiclk2 with SMTP id lk2so77302137wic.1; Fri, 09 Oct 2015 10:59:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:date:from:to:cc:subject:message-id:mail-followup-to :references:mime-version:content-type:content-disposition :in-reply-to:user-agent; bh=Y/uRFa08mN561dBM/mnSh0ZjnsdN6i+RF3o9I5m3iEc=; b=PNT9gF2T8KuyCoPEBrRB062um3UkmRBkkw7a7SqrH8VEdWZOXdHTVMz7ML+gGjrIfQ 0k7hxqejDTJTA6P/Rriu9ITAgvOzWAvt3fmwcmQFd1JibCy29794WvnTn+JhfUiRFowQ Z8vijxHHtipkUeD0/JdAkzvGN0tT8u0yFLKqgl5uVR055ddVxaOLhnCiLNuRXqcS5lOl ua5VJWhZF6h/3GPw36P53t0G/eEGWAC+c0v1BtSIpkrVVEAYU4Aucp61XoIGPjO8dr7h 6QtIREr4cGlgDiG4o4I86LVJeWgOALx7kiTIaMYY4YMy12oC5ZsWjZWt+6IxWoRLivYd S1kQ== X-Received: by 10.194.248.165 with SMTP id yn5mr17253978wjc.97.1444413550453; Fri, 09 Oct 2015 10:59:10 -0700 (PDT) Received: from brick.home (esn33.neoplus.adsl.tpnet.pl. [83.20.133.33]) by smtp.gmail.com with ESMTPSA id t7sm12351825wib.1.2015.10.09.10.59.08 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 09 Oct 2015 10:59:09 -0700 (PDT) Sender: =?UTF-8?Q?Edward_Tomasz_Napiera=C5=82a?= Date: Fri, 9 Oct 2015 19:59:06 +0200 From: Edward Tomasz =?utf-8?Q?Napiera=C5=82a?= To: John Baldwin Cc: "Bjoern A. Zeeb" , src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org Subject: Re: svn commit: r287934 - head/sys/boot/efi/loader Message-ID: <20151009175906.GA4501@brick.home> Mail-Followup-To: John Baldwin , "Bjoern A. Zeeb" , src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org References: <201509172036.t8HKalKU088025@repo.freebsd.org> <5683583.PWsk0G3i3G@ralph.baldwin.cx> <1581085.vcsbvoROWY@ralph.baldwin.cx> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1581085.vcsbvoROWY@ralph.baldwin.cx> User-Agent: Mutt/1.5.24 (2015-08-30) X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Oct 2015 17:59:13 -0000 On 0917T1630, John Baldwin wrote: > On Thursday, September 17, 2015 10:30:15 PM Bjoern A. Zeeb wrote: > > > > > On 17 Sep 2015, at 20:43 , John Baldwin wrote: > > > > > > On Thursday, September 17, 2015 08:36:47 PM John Baldwin wrote: > > >> Author: jhb > > >> Date: Thu Sep 17 20:36:46 2015 > > >> New Revision: 287934 > > >> URL: https://svnweb.freebsd.org/changeset/base/287934 > > >> > > >> Log: > > >> The EFI boot loader allocates a single chunk of contiguous memory to > > >> hold the kernel, modules, and any other loaded data. This memory block > > >> is relocated to the kernel's expected location during the transfer of > > >> control from the loader to the kernel. > > >> > > >> The GENERIC kernel on amd64 has recently grown such that a kernel + zfs.ko > > >> no longer fits in the default staging size. Bump the default size from > > >> 32MB to 48MB to provide more breathing room. > > > > > > I believe that this should work fine for any system with 64MB of RAM. One > > > downside of the static size is that the loader fails if it can't allocate > > > a contiguous staging size (it isn't able to grow the staging area on > > > demand). > > > > how do md_images work in that case? > > The md_image has to fit into the same staging area (kernel plus any other > files loaded by the loader including modules and md_images all have to fit > in the staging area). That was the original motivation for making the > staging area a build-time tunable rather than always hardcoded at 32MB so > that people who wished to deploy a large md_image can use a make flag to > build a loader with a larger staging size (I tested this with a 200+MB > mfsroot). What would be required to get rid of that limitation altogether, ie make it dynamic? Right now it's quite a regression compared to the usual (non-UEFI) loader.