From: Thomas Gleixner <tglx@linutronix.de>
To: Eric DeVolder <eric.devolder@oracle.com>,
linux-kernel@vger.kernel.org, x86@kernel.org,
kexec@lists.infradead.org, ebiederm@xmission.com,
dyoung@redhat.com, bhe@redhat.com, vgoyal@redhat.com
Cc: mingo@redhat.com, bp@alien8.de, dave.hansen@linux.intel.com,
hpa@zytor.com, nramas@linux.microsoft.com,
thomas.lendacky@amd.com, robh@kernel.org, efault@gmx.de,
rppt@kernel.org, david@redhat.com, sourabhjain@linux.ibm.com,
konrad.wilk@oracle.com, boris.ostrovsky@oracle.com
Subject: Re: [PATCH v18 5/7] kexec: exclude hot remove cpu from elfcorehdr notes
Date: Wed, 08 Feb 2023 14:44:32 +0100 [thread overview]
Message-ID: <87h6vw2rwf.ffs@tglx> (raw)
In-Reply-To: <dd03f47a-0017-6239-04e9-e796dca03c0c@oracle.com>
Eric!
On Tue, Feb 07 2023 at 11:23, Eric DeVolder wrote:
> On 2/1/23 05:33, Thomas Gleixner wrote:
>
> So my latest solution is introduce two new CPUHP states, CPUHP_AP_ELFCOREHDR_ONLINE
> for onlining and CPUHP_BP_ELFCOREHDR_OFFLINE for offlining. I'm open to better names.
>
> The CPUHP_AP_ELFCOREHDR_ONLINE needs to be placed after CPUHP_BRINGUP_CPU. My
> attempts at locating this state failed when inside the STARTING section, so I located
> this just inside the ONLINE sectoin. The crash hotplug handler is registered on
> this state as the callback for the .startup method.
>
> The CPUHP_BP_ELFCOREHDR_OFFLINE needs to be placed before CPUHP_TEARDOWN_CPU, and I
> placed it at the end of the PREPARE section. This crash hotplug handler is also
> registered on this state as the callback for the .teardown method.
TBH, that's still overengineered. Something like this:
bool cpu_is_alive(unsigned int cpu)
{
struct cpuhp_cpu_state *st = per_cpu_ptr(&cpuhp_state, cpu);
return data_race(st->state) <= CPUHP_AP_IDLE_DEAD;
}
and use this to query the actual state at crash time. That spares all
those callback heuristics.
> I'm making my way though percpu crash_notes, elfcorehdr, vmcoreinfo,
> makedumpfile and (the consumer of it all) the userspace crash utility,
> in order to understand the impact of moving from for_each_present_cpu()
> to for_each_online_cpu().
Is the packing actually worth the trouble? What's the actual win?
Thanks,
tglx
_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
WARNING: multiple messages have this Message-ID (diff)
From: Thomas Gleixner <tglx@linutronix.de>
To: Eric DeVolder <eric.devolder@oracle.com>,
linux-kernel@vger.kernel.org, x86@kernel.org,
kexec@lists.infradead.org, ebiederm@xmission.com,
dyoung@redhat.com, bhe@redhat.com, vgoyal@redhat.com
Cc: mingo@redhat.com, bp@alien8.de, dave.hansen@linux.intel.com,
hpa@zytor.com, nramas@linux.microsoft.com,
thomas.lendacky@amd.com, robh@kernel.org, efault@gmx.de,
rppt@kernel.org, david@redhat.com, sourabhjain@linux.ibm.com,
konrad.wilk@oracle.com, boris.ostrovsky@oracle.com
Subject: Re: [PATCH v18 5/7] kexec: exclude hot remove cpu from elfcorehdr notes
Date: Wed, 08 Feb 2023 14:44:32 +0100 [thread overview]
Message-ID: <87h6vw2rwf.ffs@tglx> (raw)
In-Reply-To: <dd03f47a-0017-6239-04e9-e796dca03c0c@oracle.com>
Eric!
On Tue, Feb 07 2023 at 11:23, Eric DeVolder wrote:
> On 2/1/23 05:33, Thomas Gleixner wrote:
>
> So my latest solution is introduce two new CPUHP states, CPUHP_AP_ELFCOREHDR_ONLINE
> for onlining and CPUHP_BP_ELFCOREHDR_OFFLINE for offlining. I'm open to better names.
>
> The CPUHP_AP_ELFCOREHDR_ONLINE needs to be placed after CPUHP_BRINGUP_CPU. My
> attempts at locating this state failed when inside the STARTING section, so I located
> this just inside the ONLINE sectoin. The crash hotplug handler is registered on
> this state as the callback for the .startup method.
>
> The CPUHP_BP_ELFCOREHDR_OFFLINE needs to be placed before CPUHP_TEARDOWN_CPU, and I
> placed it at the end of the PREPARE section. This crash hotplug handler is also
> registered on this state as the callback for the .teardown method.
TBH, that's still overengineered. Something like this:
bool cpu_is_alive(unsigned int cpu)
{
struct cpuhp_cpu_state *st = per_cpu_ptr(&cpuhp_state, cpu);
return data_race(st->state) <= CPUHP_AP_IDLE_DEAD;
}
and use this to query the actual state at crash time. That spares all
those callback heuristics.
> I'm making my way though percpu crash_notes, elfcorehdr, vmcoreinfo,
> makedumpfile and (the consumer of it all) the userspace crash utility,
> in order to understand the impact of moving from for_each_present_cpu()
> to for_each_online_cpu().
Is the packing actually worth the trouble? What's the actual win?
Thanks,
tglx
next prev parent reply other threads:[~2023-02-08 13:44 UTC|newest]
Thread overview: 70+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-01-31 22:42 [PATCH v18 0/7] crash: Kernel handling of CPU and memory hot un/plug Eric DeVolder
2023-01-31 22:42 ` Eric DeVolder
2023-01-31 22:42 ` [PATCH v18 1/7] crash: move a few code bits to setup support of crash hotplug Eric DeVolder
2023-01-31 22:42 ` Eric DeVolder
2023-01-31 22:42 ` [PATCH v18 2/7] crash: prototype change for crash_prepare_elf64_headers() Eric DeVolder
2023-01-31 22:42 ` Eric DeVolder
2023-01-31 22:42 ` [PATCH v18 3/7] crash: add generic infrastructure for crash hotplug support Eric DeVolder
2023-01-31 22:42 ` Eric DeVolder
2023-02-09 19:10 ` Sourabh Jain
2023-02-09 19:10 ` Sourabh Jain
2023-02-10 16:51 ` Eric DeVolder
2023-02-10 16:51 ` Eric DeVolder
2023-01-31 22:42 ` [PATCH v18 4/7] kexec: exclude elfcorehdr from the segment digest Eric DeVolder
2023-01-31 22:42 ` Eric DeVolder
2023-01-31 22:42 ` [PATCH v18 5/7] kexec: exclude hot remove cpu from elfcorehdr notes Eric DeVolder
2023-01-31 22:42 ` Eric DeVolder
2023-02-01 11:33 ` Thomas Gleixner
2023-02-01 11:33 ` Thomas Gleixner
2023-02-06 8:12 ` Sourabh Jain
2023-02-06 8:12 ` Sourabh Jain
2023-02-06 13:03 ` Thomas Gleixner
2023-02-06 13:03 ` Thomas Gleixner
2023-02-07 17:23 ` Eric DeVolder
2023-02-07 17:23 ` Eric DeVolder
2023-02-08 13:44 ` Thomas Gleixner [this message]
2023-02-08 13:44 ` Thomas Gleixner
2023-02-09 17:31 ` Eric DeVolder
2023-02-09 17:31 ` Eric DeVolder
2023-02-09 18:43 ` Sourabh Jain
2023-02-09 18:43 ` Sourabh Jain
2023-02-09 19:39 ` Eric DeVolder
2023-02-09 19:39 ` Eric DeVolder
2023-02-10 6:29 ` Sourabh Jain
2023-02-10 6:29 ` Sourabh Jain
2023-02-11 0:35 ` Eric DeVolder
2023-02-11 0:35 ` Eric DeVolder
2023-02-13 4:40 ` Sourabh Jain
2023-02-13 4:40 ` Sourabh Jain
2023-02-13 12:52 ` Thomas Gleixner
2023-02-13 12:52 ` Thomas Gleixner
2023-02-15 2:53 ` Sourabh Jain
2023-02-15 2:53 ` Sourabh Jain
2023-02-28 12:44 ` Baoquan He
2023-02-28 12:44 ` Baoquan He
2023-02-28 18:52 ` Eric DeVolder
2023-02-28 18:52 ` Eric DeVolder
2023-03-01 15:48 ` Eric DeVolder
2023-03-01 15:48 ` Eric DeVolder
2023-03-02 10:51 ` Baoquan He
2023-03-02 10:51 ` Baoquan He
2023-03-02 5:23 ` Sourabh Jain
2023-03-02 5:23 ` Sourabh Jain
2023-02-23 20:34 ` Eric DeVolder
2023-02-23 20:34 ` Eric DeVolder
2023-02-24 8:34 ` Sourabh Jain
2023-02-24 8:34 ` Sourabh Jain
2023-02-24 20:16 ` Eric DeVolder
2023-02-24 20:16 ` Eric DeVolder
2023-02-27 6:11 ` Sourabh Jain
2023-02-27 6:11 ` Sourabh Jain
2023-02-28 21:50 ` Eric DeVolder
2023-02-28 21:50 ` Eric DeVolder
2023-03-01 6:22 ` Sourabh Jain
2023-03-01 6:22 ` Sourabh Jain
2023-03-01 14:16 ` Eric DeVolder
2023-03-01 14:16 ` Eric DeVolder
2023-01-31 22:42 ` [PATCH v18 6/7] crash: memory and cpu hotplug sysfs attributes Eric DeVolder
2023-01-31 22:42 ` Eric DeVolder
2023-01-31 22:42 ` [PATCH v18 7/7] x86/crash: add x86 crash hotplug support Eric DeVolder
2023-01-31 22:42 ` Eric DeVolder
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=87h6vw2rwf.ffs@tglx \
--to=tglx@linutronix.de \
--cc=bhe@redhat.com \
--cc=boris.ostrovsky@oracle.com \
--cc=bp@alien8.de \
--cc=dave.hansen@linux.intel.com \
--cc=david@redhat.com \
--cc=dyoung@redhat.com \
--cc=ebiederm@xmission.com \
--cc=efault@gmx.de \
--cc=eric.devolder@oracle.com \
--cc=hpa@zytor.com \
--cc=kexec@lists.infradead.org \
--cc=konrad.wilk@oracle.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=nramas@linux.microsoft.com \
--cc=robh@kernel.org \
--cc=rppt@kernel.org \
--cc=sourabhjain@linux.ibm.com \
--cc=thomas.lendacky@amd.com \
--cc=vgoyal@redhat.com \
--cc=x86@kernel.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.