[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20180723143443.GD18181@dhcp22.suse.cz>
Date: Mon, 23 Jul 2018 16:34:43 +0200
From: Michal Hocko <mhocko@...nel.org>
To: Baoquan He <bhe@...hat.com>
Cc: Andrew Morton <akpm@...ux-foundation.org>,
linux-kernel@...r.kernel.org, robh+dt@...nel.org,
dan.j.williams@...el.com, nicolas.pitre@...aro.org,
josh@...htriplett.org, fengguang.wu@...el.com, bp@...e.de,
andy.shevchenko@...il.com, patrik.r.jakobsson@...il.com,
airlied@...ux.ie, kys@...rosoft.com, haiyangz@...rosoft.com,
sthemmin@...rosoft.com, dmitry.torokhov@...il.com,
frowand.list@...il.com, keith.busch@...el.com,
jonathan.derrick@...el.com, lorenzo.pieralisi@....com,
bhelgaas@...gle.com, tglx@...utronix.de, brijesh.singh@....com,
jglisse@...hat.com, thomas.lendacky@....com,
gregkh@...uxfoundation.org, baiyaowei@...s.chinamobile.com,
richard.weiyang@...il.com, devel@...uxdriverproject.org,
linux-input@...r.kernel.org, linux-nvdimm@...ts.01.org,
devicetree@...r.kernel.org, linux-pci@...r.kernel.org,
ebiederm@...ssion.com, vgoyal@...hat.com, dyoung@...hat.com,
yinghai@...nel.org, monstr@...str.eu, davem@...emloft.net,
chris@...kel.net, jcmvbkbc@...il.com, gustavo@...ovan.org,
maarten.lankhorst@...ux.intel.com, seanpaul@...omium.org,
linux-parisc@...r.kernel.org, linuxppc-dev@...ts.ozlabs.org,
kexec@...ts.infradead.org
Subject: Re: [PATCH v7 4/4] kexec_file: Load kernel at top of system RAM if
required
On Thu 19-07-18 23:17:53, Baoquan He wrote:
> Kexec has been a formal feature in our distro, and customers owning
> those kind of very large machine can make use of this feature to speed
> up the reboot process. On uefi machine, the kexec_file loading will
> search place to put kernel under 4G from top to down. As we know, the
> 1st 4G space is DMA32 ZONE, dma, pci mmcfg, bios etc all try to consume
> it. It may have possibility to not be able to find a usable space for
> kernel/initrd. From the top down of the whole memory space, we don't
> have this worry.
I do not have the full context here but let me note that you should be
careful when doing top-down reservation because you can easily get into
hotplugable memory and break the hotremove usecase. We even warn when
this is done. See memblock_find_in_range_node
--
Michal Hocko
SUSE Labs
Powered by blists - more mailing lists