nvdimm.lists.linux.dev archive mirror
 help / color / mirror / Atom feed
From: Baoquan He <bhe@redhat.com>
To: Andrew Morton <akpm@linux-foundation.org>
Cc: nicolas.pitre@linaro.org, brijesh.singh@amd.com,
	devicetree@vger.kernel.org, airlied@linux.ie,
	linux-pci@vger.kernel.org, richard.weiyang@gmail.com,
	jcmvbkbc@gmail.com, baiyaowei@cmss.chinamobile.com,
	kys@microsoft.com, frowand.list@gmail.com, tglx@linutronix.de,
	lorenzo.pieralisi@arm.com, sthemmin@microsoft.com,
	linux-nvdimm@lists.01.org, patrik.r.jakobsson@gmail.com,
	andy.shevchenko@gmail.com, linux-input@vger.kernel.org,
	gustavo@padovan.org, bp@suse.de, dyoung@redhat.com,
	thomas.lendacky@amd.com, haiyangz@microsoft.com,
	maarten.lankhorst@linux.intel.com, josh@joshtriplett.org,
	jglisse@redhat.com, robh+dt@kernel.org, seanpaul@chromium.org,
	bhelgaas@google.com, yinghai@kernel.org,
	jonathan.derrick@intel.com, chris@zankel.net, monstr@monstr.eu,
	linux-parisc@vger.kernel.org, gregkh@linuxfoundation.org,
	dmitry.torokhov@gmail.com, kexec@lists.infradead.org,
	linux-kernel@vger.kernel.org, ebiederm@xmission.com,
	devel@linuxdriverproject.org, fengguang.wu@intel.com,
	linuxppc-dev@lists.ozlabs.org, davem@davemloft.net
Subject: Re: [PATCH v7 4/4] kexec_file: Load kernel at top of system RAM if required
Date: Thu, 19 Jul 2018 23:17:53 +0800	[thread overview]
Message-ID: <20180719151753.GB7147@localhost.localdomain> (raw)
In-Reply-To: <20180718153326.b795e9ea7835432a56cd7011@linux-foundation.org>

Hi Andrew,

On 07/18/18 at 03:33pm, Andrew Morton wrote:
> On Wed, 18 Jul 2018 10:49:44 +0800 Baoquan He <bhe@redhat.com> wrote:
> > For kexec_file loading, if kexec_buf.top_down is 'true', the memory which
> > is used to load kernel/initrd/purgatory is supposed to be allocated from
> > top to down. This is what we have been doing all along in the old kexec
> > loading interface and the kexec loading is still default setting in some
> > distributions. However, the current kexec_file loading interface doesn't
> > do like this. The function arch_kexec_walk_mem() it calls ignores checking
> > kexec_buf.top_down, but calls walk_system_ram_res() directly to go through
> > all resources of System RAM from bottom to up, to try to find memory region
> > which can contain the specific kexec buffer, then call locate_mem_hole_callback()
> > to allocate memory in that found memory region from top to down. This brings
> > confusion especially when KASLR is widely supported , users have to make clear
> > why kexec/kdump kernel loading position is different between these two
> > interfaces in order to exclude unnecessary noises. Hence these two interfaces
> > need be unified on behaviour.
> As far as I can tell, the above is the whole reason for the patchset,
> yes?  To avoid confusing users.

In fact, it's not just trying to avoid confusing users. Kexec loading
and kexec_file loading are just do the same thing in essence. Just we
need do kernel image verification on uefi system, have to port kexec
loading code to kernel. 

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. 

And at the first post, I just posted below with AKASHI's
walk_system_ram_res_rev() version. Later you suggested to use
list_head to link child sibling of resource, see what the code change
looks like.

Then I posted v2
Rob Herring mentioned that other components which has this tree struct
have planned to do the same thing, replacing the singly linked list with
list_head to link resource child sibling. Just quote Rob's words as
below. I think this could be another reason.

~~~~~ From Rob
The DT struct device_node also has the same tree structure with
parent, child, sibling pointers and converting to list_head had been
on the todo list for a while. ACPI also has some tree walking
functions (drivers/acpi/acpica/pstree.c). Perhaps there should be a
common tree struct and helpers defined either on top of list_head or a
new struct if that saves some size.

> Is that sufficient?  Can we instead simplify their lives by providing
> better documentation or informative printks or better Kconfig text,
> etc?
> And who *are* the people who are performing this configuration?  Random
> system administrators?  Linux distro engineers?  If the latter then
> they presumably aren't easily confused!

Kexec was invented for kernel developer to speed up their kernel
rebooting. Now high end sever admin, kernel developer and QE are also
keen to use it to reboot large box for faster feature testing, bug
debugging. Kernel dev could know this well, about kernel loading
position, admin or QE might not be aware of it very well. 

> In other words, I'm trying to understand how much benefit this patchset
> will provide to our users as a whole.

Understood. The list_head replacing patch truly involes too many code
changes, it's risky. I am willing to try any idea from reviewers, won't
persuit they have to be accepted finally. If don't have a try, we don't
know what it looks like, and what impact it may have. I am fine to take
AKASHI's simple version of walk_system_ram_res_rev() to lower risk, even
though it could be a little bit low efficient.

Linux-nvdimm mailing list

  reply	other threads:[~2018-07-19 15:18 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-07-18  2:49 [PATCH v7 0/4] resource: Use list_head to link sibling resource Baoquan He
2018-07-18  2:49 ` [PATCH v7 1/4] resource: Move reparent_resources() to kernel/resource.c and make it public Baoquan He
2018-07-18 16:36   ` Andy Shevchenko
2018-07-18 16:37     ` Andy Shevchenko
2018-07-19 15:18       ` Baoquan He
2018-07-18  2:49 ` [PATCH v7 2/4] resource: Use list_head to link sibling resource Baoquan He
2018-07-18  2:49 ` [PATCH v7 3/4] resource: add walk_system_ram_res_rev() Baoquan He
2018-07-18  2:49 ` [PATCH v7 4/4] kexec_file: Load kernel at top of system RAM if required Baoquan He
2018-07-18 22:33   ` Andrew Morton
2018-07-19 15:17     ` Baoquan He [this message]
2018-07-19 19:44       ` Andrew Morton
2018-07-25  2:21         ` Baoquan He
2018-07-23 14:34       ` Michal Hocko
2018-07-25  6:48         ` Baoquan He
2018-07-26 12:59           ` Michal Hocko
2018-07-26 13:09             ` Baoquan He
2018-07-26 13:12               ` Michal Hocko
2018-07-26 13:14                 ` Michal Hocko
2018-07-26 13:37                   ` Baoquan He
2018-07-26 14:01                     ` Michal Hocko
2018-07-26 15:10                       ` Baoquan He

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:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20180719151753.GB7147@localhost.localdomain \
    --to=bhe@redhat.com \
    --cc=airlied@linux.ie \
    --cc=akpm@linux-foundation.org \
    --cc=andy.shevchenko@gmail.com \
    --cc=baiyaowei@cmss.chinamobile.com \
    --cc=bhelgaas@google.com \
    --cc=bp@suse.de \
    --cc=brijesh.singh@amd.com \
    --cc=chris@zankel.net \
    --cc=davem@davemloft.net \
    --cc=devel@linuxdriverproject.org \
    --cc=devicetree@vger.kernel.org \
    --cc=dmitry.torokhov@gmail.com \
    --cc=dyoung@redhat.com \
    --cc=ebiederm@xmission.com \
    --cc=fengguang.wu@intel.com \
    --cc=frowand.list@gmail.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=gustavo@padovan.org \
    --cc=haiyangz@microsoft.com \
    --cc=jcmvbkbc@gmail.com \
    --cc=jglisse@redhat.com \
    --cc=jonathan.derrick@intel.com \
    --cc=josh@joshtriplett.org \
    --cc=kexec@lists.infradead.org \
    --cc=kys@microsoft.com \
    --cc=linux-input@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-nvdimm@lists.01.org \
    --cc=linux-parisc@vger.kernel.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=linuxppc-dev@lists.ozlabs.org \
    --cc=lorenzo.pieralisi@arm.com \
    --cc=maarten.lankhorst@linux.intel.com \
    --cc=monstr@monstr.eu \
    --cc=nicolas.pitre@linaro.org \
    --cc=patrik.r.jakobsson@gmail.com \
    --cc=richard.weiyang@gmail.com \
    --cc=robh+dt@kernel.org \
    --cc=seanpaul@chromium.org \
    --cc=sthemmin@microsoft.com \
    --cc=tglx@linutronix.de \
    --cc=thomas.lendacky@amd.com \
    --cc=yinghai@kernel.org \


* 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;
as well as URLs for NNTP newsgroup(s).