All of lore.kernel.org
 help / color / mirror / Atom feed
From: Pratyush Yadav <pratyush@kernel.org>
To: Usama Arif <usamaarif642@gmail.com>
Cc: Andrew Morton <akpm@linux-foundation.org>,
	 rppt@kernel.org, kas@kernel.org,  changyuanl@google.com,
	 graf@amazon.com, leitao@debian.org,  thevlad@meta.com,
	 pratyush@kernel.org, dave.hansen@linux.intel.com,
	 linux-mm@kvack.org, linux-kernel@vger.kernel.org,
	 kernel-team@meta.com
Subject: Re: [PATCH v2 2/2] mm/memblock: only mark/clear KHO scratch memory when needed
Date: Thu, 27 Nov 2025 22:30:57 +0100	[thread overview]
Message-ID: <86bjknyxgu.fsf@kernel.org> (raw)
In-Reply-To: <56673a9c-a4c9-4962-baec-2d4483af3cfa@gmail.com> (Usama Arif's message of "Thu, 27 Nov 2025 21:04:58 +0000")

On Thu, Nov 27 2025, Usama Arif wrote:

> On 27/11/2025 20:55, Andrew Morton wrote:
>> On Thu, 27 Nov 2025 20:33:20 +0000 Usama Arif <usamaarif642@gmail.com> wrote:
>> 
>>> The scratch memory for kexec handover is used to bootstrap the
>>> kexec'ed kernel. It is only needed when CONFIG_KEXEC_HANDOVER
>>> is enabled and only if it is a KHO boot. Add checks to prevent
>>> marking a KHO scratch region unless needed.
>> 
>> What effect does this change have?  Lessened memory consumption,
>> presumably.  Of what magnitude and for what time period?
>
> For some context, this came out of https://lore.kernel.org/all/ba690e06-c2a1-4d2e-9428-9ca2ea9f2b86@gmail.com/
> (I should have probably added that in the commit message..)
> We are experiencing several warnings a day in meta fleet due to a warning introduced
> in that patch. We dont have CONFIG_KEXEC_HANDOVER enabled in the fleet. The IMA memory
> seems to conincide with the 1st MB, but as Mike pointed out they are different arrays
> so this scratch memory is likely not a cause of the warnings. But it is not useful (and
> was a bit confusing) seeing KHO scratch memory being marked even when KHO is disabled.

Yeah, it is not yet clear if this is really the root cause for your
issue.

>
> The imapct is as you said, but its only marked for a very short period of time.
> I think a better reason for this patch is just to not mark the memory at all when KHO
> is disabled (or not in use) for clarity.

Yeah, I don't think it will have much of a difference in practice, but I
do think it is a good correctness fix. Marking the lower 1M as scratch
is a hack to get around the limitations with KHO, and we should not be
doing that when KHO isn't involved.

-- 
Regards,
Pratyush Yadav


  reply	other threads:[~2025-11-27 21:31 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-11-27 20:33 [PATCH v2 0/2] mm: only mark/clear KHO scratch memory when needed Usama Arif
2025-11-27 20:33 ` [PATCH v2 1/2] mm/memblock: remove CONFIG_MEMBLOCK_KHO_SCRATCH option Usama Arif
2025-11-27 21:23   ` Pratyush Yadav
2025-11-28 11:57   ` Kiryl Shutsemau
2025-11-27 20:33 ` [PATCH v2 2/2] mm/memblock: only mark/clear KHO scratch memory when needed Usama Arif
2025-11-27 20:55   ` Andrew Morton
2025-11-27 21:04     ` Usama Arif
2025-11-27 21:30       ` Pratyush Yadav [this message]
2025-11-27 21:37   ` Pratyush Yadav
2025-11-28  8:26   ` Mike Rapoport

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=86bjknyxgu.fsf@kernel.org \
    --to=pratyush@kernel.org \
    --cc=akpm@linux-foundation.org \
    --cc=changyuanl@google.com \
    --cc=dave.hansen@linux.intel.com \
    --cc=graf@amazon.com \
    --cc=kas@kernel.org \
    --cc=kernel-team@meta.com \
    --cc=leitao@debian.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=rppt@kernel.org \
    --cc=thevlad@meta.com \
    --cc=usamaarif642@gmail.com \
    /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.