linuxppc-dev.lists.ozlabs.org archive mirror
 help / color / mirror / Atom feed
From: Sourabh Jain <sourabhjain@linux.ibm.com>
To: Baoquan He <bhe@redhat.com>
Cc: linuxppc-dev@ozlabs.org, kexec@lists.infradead.org,
	hbathini@linux.ibm.com
Subject: Re: [RFC PATCH 0/5] Avoid kdump service reload on CPU hotplug events
Date: Thu, 24 Feb 2022 13:21:40 +0530	[thread overview]
Message-ID: <091f4e0b-540b-ee5b-c07c-0362d53821df@linux.ibm.com> (raw)
In-Reply-To: <YhRdfu++s5dJMS5L@MiWiFi-R3L-srv>

Hello Baoquan,

> Hi,
>
> On 02/21/22 at 02:16pm, Sourabh Jain wrote:
>> On hotplug event (CPU/memory) the CPU information prepared for the kdump kernel
>> becomes stale unless it is prepared again. To keep the CPU information
>> up-to-date a kdump service reload is triggered via the udev rule.
>>
>> The above approach has two downsides:
>>
>> 1) The udev rules are prone to races if hotplug event is frequent. The time is
>>     taken to settle down all the kdump service reload requested is significant
>>     when multiple CPU/memory hotplug is performed at the same time. This creates
>>     a window where kernel crash might not lead to successfully dump collection.
>>
>> 2) Unnecessary CPU cycles are consumed to reload all the kdump components
>>     including initrd, vmlinux, FDT, etc. whereas only one component needs to
>>     update that is FDT.
> I roughly went through this sereis, while haven't read the code
> carefully. Seems the issue and the approach are similar to what below
> patchset is doing. Do you notice below patchset from Oracle engineer?
> And is there stuff the ppc code can be rebased on and reused?
>
> [PATCH v4 00/10] crash: Kernel handling of CPU and memory hot un/plug
> https://lore.kernel.org/all/20220209195706.51522-1-eric.devolder@oracle.com/T/#u

Thanks for the suggestion. I have seen earlier versions of this patch series
but since it did not have support for kexec_load system call we tried 
implementing
something from scratch.

Since Eric's added support for kexec_load and has a generic handler for 
CPU and
memory hotplug let me see if I can rebase my PowerPC changes on top of 
his patches.
The major difference across the distro is that on PowerPC we need to 
update FDT instead
of elfcorehdr on hotplug event.

Thanks,
Sourabh Jain


      reply	other threads:[~2022-02-24  8:11 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-02-21  8:46 [RFC PATCH 0/5] Avoid kdump service reload on CPU hotplug events Sourabh Jain
2022-02-21  8:46 ` [RFC PATCH 1/5] powerpc/kdump: export functions from file_load_64.c Sourabh Jain
2022-02-21  8:46 ` [RFC PATCH 2/5] powerpc/kdump: setup kexec crash FDT Sourabh Jain
2022-02-21  8:46 ` [RFC PATCH 3/5] powerpc/kdump: update kexec crash FDT on CPU hot add event Sourabh Jain
2022-02-21  8:46 ` [RFC PATCH 4/5] powerpc/kdump: enable kexec_file_load system call to use kexec crash FDT Sourabh Jain
2022-02-21  8:46 ` [RFC PATCH 5/5] powerpc/kdump: export kexec crash FDT details via sysfs Sourabh Jain
2022-02-22  3:50 ` [RFC PATCH 0/5] Avoid kdump service reload on CPU hotplug events Baoquan He
2022-02-24  7:51   ` Sourabh Jain [this message]

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=091f4e0b-540b-ee5b-c07c-0362d53821df@linux.ibm.com \
    --to=sourabhjain@linux.ibm.com \
    --cc=bhe@redhat.com \
    --cc=hbathini@linux.ibm.com \
    --cc=kexec@lists.infradead.org \
    --cc=linuxppc-dev@ozlabs.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;
as well as URLs for NNTP newsgroup(s).