From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id F1DA93B2A0 for ; Thu, 27 Nov 2025 21:31:04 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1764279070; cv=none; b=omo2IXwtMezezrCeYNgw6T6yNO1Al5nneXg0t82Cs5J7j0ciUNSeJKdUxqyi9QZ3ESYr9KlsgqAMhYNnnPfYpjBPyEErnqJ5Cdpl0rLmnqdoBgd9VKT94AXOyamZcdnHNnP4pkoXwX68mfJCe+E5qFa2R6x5kHnT2jpJuTJF40s= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1764279070; c=relaxed/simple; bh=ywbAAzd9Kp7GEcrsxuGuM12fYx11Cs7LW5tYL+saSPw=; h=From:To:Cc:Subject:In-Reply-To:References:Date:Message-ID: MIME-Version:Content-Type; b=qTmhQyngEDlSdYjYa17v8Rh012ZxqIYKGoFqYFCxVYdsyJIIsAOdr96vi5zmIYzBLMsbJRvEcVMKYt+SBQHsTLPtLGtTlYH7F/0rXW0AGz8AgQ04lqQ7LG2qIflC2hN0DYrJQgOazifvMLNeKQIkneclAINtDML86HqKFq2ouFw= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=Odhu/0s4; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="Odhu/0s4" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 841CCC4CEF8; Thu, 27 Nov 2025 21:31:00 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1764279064; bh=ywbAAzd9Kp7GEcrsxuGuM12fYx11Cs7LW5tYL+saSPw=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=Odhu/0s4Ls+k/BbLn0GUp1ajsRCOtvnD2Gsb61UNpir+QhSghK5KfbFPHa8PAiDi/ 0/KZ5N5Rv6Y+aubd380RjJVmgeerBLpFbk05KEjdBJrcTR7fuUm3EpbjrZxmp+VecH RIuUqmD+GixOUpsqLgZG9UlRg3hCV4gENdFqnRQ+ZWJy8n48j9WW6bKyBAAes46h98 r14CWVLH7pmo2t2zWHEd4/CR7/DxK6iPNTdlDF+JlFtrOue2HS7pfikfi2XSvHRFEP grLkQ6wikItmBVu9HybulG7JB6s6/i3+gAufCN3DqwJ4s7+0c5vmm0F4w0scPqKGqC VUCFv1hohURIg== From: Pratyush Yadav To: Usama Arif Cc: Andrew Morton , 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 In-Reply-To: <56673a9c-a4c9-4962-baec-2d4483af3cfa@gmail.com> (Usama Arif's message of "Thu, 27 Nov 2025 21:04:58 +0000") References: <20251127203724.3177621-1-usamaarif642@gmail.com> <20251127203724.3177621-3-usamaarif642@gmail.com> <20251127125539.98b2f148c6225f1cb7c9d045@linux-foundation.org> <56673a9c-a4c9-4962-baec-2d4483af3cfa@gmail.com> Date: Thu, 27 Nov 2025 22:30:57 +0100 Message-ID: <86bjknyxgu.fsf@kernel.org> User-Agent: Gnus/5.13 (Gnus v5.13) Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain 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 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