From: Pratyush Yadav <pratyush@kernel.org>
To: Breno Leitao <leitao@debian.org>
Cc: Pratyush Yadav <pratyush@kernel.org>,
Changyuan Lyu <changyuanl@google.com>,
rppt@kernel.org, akpm@linux-foundation.org,
linux-kernel@vger.kernel.org, anthony.yznaga@oracle.com,
arnd@arndb.de, ashish.kalra@amd.com, benh@kernel.crashing.org,
bp@alien8.de, catalin.marinas@arm.com, corbet@lwn.net,
dave.hansen@linux.intel.com, devicetree@vger.kernel.org,
dwmw2@infradead.org, ebiederm@xmission.com, graf@amazon.com,
hpa@zytor.com, jgowans@amazon.com, kexec@lists.infradead.org,
krzk@kernel.org, linux-arm-kernel@lists.infradead.org,
linux-doc@vger.kernel.org, linux-mm@kvack.org, luto@kernel.org,
mark.rutland@arm.com, mingo@redhat.com,
pasha.tatashin@soleen.com, pbonzini@redhat.com,
peterz@infradead.org, robh@kernel.org, rostedt@goodmis.org,
saravanak@google.com, skinsburskii@linux.microsoft.com,
tglx@linutronix.de, thomas.lendacky@amd.com, will@kernel.org,
x86@kernel.org
Subject: Re: [PATCH v8 01/17] memblock: add MEMBLOCK_RSRV_KERN flag
Date: Tue, 14 Oct 2025 15:10:37 +0200 [thread overview]
Message-ID: <mafs0cy6pljci.fsf@kernel.org> (raw)
In-Reply-To: <2ege2jfbevtunhxsnutbzde7cqwgu5qbj4bbuw2umw7ke7ogcn@5wtskk4exzsi> (Breno Leitao's message of "Tue, 14 Oct 2025 01:34:07 -0700")
On Tue, Oct 14 2025, Breno Leitao wrote:
> Hello Pratyush,
>
> On Mon, Oct 13, 2025 at 06:40:09PM +0200, Pratyush Yadav wrote:
>> On Mon, Oct 13 2025, Pratyush Yadav wrote:
>> >
>> > I suppose this would be useful. I think enabling memblock debug prints
>> > would also be helpful (using the "memblock=debug" commandline parameter)
>> > if it doesn't impact your production environment too much.
>>
>> Actually, I think "memblock=debug" is going to be the more useful thing
>> since it would also show what function allocated the overlapping range
>> and the flags it was allocated with.
>>
>> On my qemu VM with KVM, this results in around 70 prints from memblock.
>> So it adds a bit of extra prints but nothing that should be too
>> disrupting I think. Plus, only at boot so the worst thing you get is
>> slightly slower boot times.
>
> Unfortunately this issue is happening on production systems, and I don't
> have an easy way to reproduce it _yet_.
>
> At the same time, "memblock=debug" has two problems:
>
> 1) It slows the boot time as you suggested. Boot time at large
> environments is SUPER critical and time sensitive. It is a bit
> weird, but it is common for machines in production to kexec
> _thousands_ of times, and kexecing is considered downtime.
I don't know if it would make a real enough difference on boot times,
only that it should theoretically affect it, mainly if you are using
serial for dmesg logs. Anyway, that's your production environment so you
know best.
>
> This would be useful if I find some hosts getting this issue, and
> then I can easily enable the extra information to collect what
> I need, but, this didn't pan out because the hosts I got
> `memblock=debug` didn't collaborate.
>
> 2) "memblock=debug" is verbose for all cases, which also not necessary
> the desired behaviour. I am more interested in only being verbose
> when there is a known problem.
>
> That said, my suggestion is to only dump extra information when something goes
> wrong, not affecting the boot time neither boot verbosity.
>
With your proposed change, we only know what the overlapping area is,
but not who allocated it. I don't see how that can be done when the
error is detected. memblock debug lets us know that, which is why I
suggested it.
--
Regards,
Pratyush Yadav
next prev parent reply other threads:[~2025-10-14 13:10 UTC|newest]
Thread overview: 36+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-05-09 7:46 [PATCH v8 00/17] kexec: introduce Kexec HandOver (KHO) Changyuan Lyu
2025-05-09 7:46 ` [PATCH v8 01/17] memblock: add MEMBLOCK_RSRV_KERN flag Changyuan Lyu
2025-10-10 9:33 ` Breno Leitao
2025-10-13 14:59 ` Pratyush Yadav
2025-10-13 16:40 ` Pratyush Yadav
2025-10-14 8:34 ` Breno Leitao
2025-10-14 13:10 ` Pratyush Yadav [this message]
2025-11-05 10:18 ` Breno Leitao
2025-11-06 8:24 ` Mike Rapoport
2025-05-09 7:46 ` [PATCH v8 02/17] memblock: Add support for scratch memory Changyuan Lyu
2025-05-09 7:46 ` [PATCH v8 03/17] memblock: introduce memmap_init_kho_scratch() Changyuan Lyu
2025-05-09 7:46 ` [PATCH v8 04/17] kexec: add Kexec HandOver (KHO) generation helpers Changyuan Lyu
2025-05-09 7:46 ` [PATCH v8 05/17] kexec: add KHO parsing support Changyuan Lyu
2025-05-09 7:46 ` [PATCH v8 06/17] kexec: enable KHO support for memory preservation Changyuan Lyu
2025-05-09 7:46 ` [PATCH v8 07/17] kexec: add KHO support to kexec file loads Changyuan Lyu
2025-05-09 7:46 ` [PATCH v8 08/17] kexec: add config option for KHO Changyuan Lyu
2025-05-09 7:46 ` [PATCH v8 09/17] arm64: add KHO support Changyuan Lyu
2025-05-09 7:46 ` [PATCH v8 10/17] x86/setup: use memblock_reserve_kern for memory used by kernel Changyuan Lyu
2025-05-09 7:46 ` [PATCH v8 11/17] x86/kexec: add support for passing kexec handover (KHO) data Changyuan Lyu
2025-05-09 7:46 ` [PATCH v8 12/17] x86/e820: temporarily enable KHO scratch for memory below 1M Changyuan Lyu
2025-11-24 19:24 ` Usama Arif
2025-11-25 0:56 ` H. Peter Anvin
2025-11-25 12:23 ` Pratyush Yadav
2025-11-25 13:53 ` Mike Rapoport
2025-11-25 13:15 ` Pratyush Yadav
2025-11-25 13:50 ` Mike Rapoport
2025-11-25 18:47 ` Usama Arif
2025-11-26 6:14 ` Mike Rapoport
2025-11-26 7:25 ` Usama Arif
2025-11-25 14:31 ` Usama Arif
2025-11-25 14:39 ` Pratyush Yadav
2025-05-09 7:46 ` [PATCH v8 13/17] x86/boot: make sure KASLR does not step over KHO preserved memory Changyuan Lyu
2025-05-09 7:46 ` [PATCH v8 14/17] x86/Kconfig: enable kexec handover for 64 bits Changyuan Lyu
2025-05-09 7:46 ` [PATCH v8 15/17] memblock: add KHO support for reserve_mem Changyuan Lyu
2025-05-09 7:46 ` [PATCH v8 16/17] Documentation: add documentation for KHO Changyuan Lyu
2025-05-09 7:46 ` [PATCH v8 17/17] Documentation: KHO: Add memblock bindings Changyuan Lyu
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=mafs0cy6pljci.fsf@kernel.org \
--to=pratyush@kernel.org \
--cc=akpm@linux-foundation.org \
--cc=anthony.yznaga@oracle.com \
--cc=arnd@arndb.de \
--cc=ashish.kalra@amd.com \
--cc=benh@kernel.crashing.org \
--cc=bp@alien8.de \
--cc=catalin.marinas@arm.com \
--cc=changyuanl@google.com \
--cc=corbet@lwn.net \
--cc=dave.hansen@linux.intel.com \
--cc=devicetree@vger.kernel.org \
--cc=dwmw2@infradead.org \
--cc=ebiederm@xmission.com \
--cc=graf@amazon.com \
--cc=hpa@zytor.com \
--cc=jgowans@amazon.com \
--cc=kexec@lists.infradead.org \
--cc=krzk@kernel.org \
--cc=leitao@debian.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-doc@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=luto@kernel.org \
--cc=mark.rutland@arm.com \
--cc=mingo@redhat.com \
--cc=pasha.tatashin@soleen.com \
--cc=pbonzini@redhat.com \
--cc=peterz@infradead.org \
--cc=robh@kernel.org \
--cc=rostedt@goodmis.org \
--cc=rppt@kernel.org \
--cc=saravanak@google.com \
--cc=skinsburskii@linux.microsoft.com \
--cc=tglx@linutronix.de \
--cc=thomas.lendacky@amd.com \
--cc=will@kernel.org \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox