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 86D8037B3FE for ; Mon, 18 May 2026 17:04:57 +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=1779123897; cv=none; b=tq3NAtVExdS5Qr1cLAspoy+aiEJTuMAOQI4ca1EIgoGC+TVpdkq9bh40ipRxSFB9AjYRfeOmWwFS57mNC8vkhK2ktycLjJu4MWBOCxCvbu8CeHNDWRxqyQnSHm/5VMBx0YY2Tk1aTGookzdq9NsIYa77Vw5d2N4dvL1Jfh0yJmM= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1779123897; c=relaxed/simple; bh=oF5fCKa8TBaLbZmUFVSl67crcxZy4IiTCrZvTFlW8Vc=; h=From:To:Cc:Subject:In-Reply-To:References:Date:Message-ID: MIME-Version:Content-Type; b=lkaQqG7ZEhButPwXswisdgBNQznt2lFUDGIGp5QDqUdOQh+ZLX3jCf707K9vu3c99yxEL7mcR01nWZkvUVso6qtoyBQCkH3xlrbG+fwSsbuwmtMAiq2yrexOBdXmLr4fdyQNjTu+lszRRFj7M7mZufM921JAfYGWSKVJyNNh9qI= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=NvDNMnTK; 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="NvDNMnTK" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 40798C2BCC6; Mon, 18 May 2026 17:04:55 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1779123897; bh=oF5fCKa8TBaLbZmUFVSl67crcxZy4IiTCrZvTFlW8Vc=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=NvDNMnTKzFj1hZuOpHHB4xghuVeBxnwoO6sXwaSIdz4MZOGRMHCJRMa0pyIsavGA4 ufe8NNH7VYDgF31DkRarC/2x5lLc1LGk62rP9Vk41HmSCLljA2qapXIOf8b6ZThm/n m1jqsdhTYLaJfWsWscw/LX4kDN/41E5bAfuqAv0FxZueFgHFR1flpEimM7R80iKM6/ HKKCiI1RJX3ONvr6kN2E/4g/JZ2ifYb8m0ihlj1DO8RMyqXc+vSfbXE5MDAsxOlftn hNWRp6XXJjWuRtGRu6Cni/USftVNufnssIdcambJ4YwcGoTg8itfUoT8yUD0mTfbaO qRCT8Pre9fpuA== From: Pratyush Yadav To: Mike Rapoport Cc: Pratyush Yadav , Pasha Tatashin , Alexander Graf , Muchun Song , Oscar Salvador , David Hildenbrand , Andrew Morton , Jason Miu , kexec@lists.infradead.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH 10/12] kho: extended scratch In-Reply-To: (Mike Rapoport's message of "Sun, 17 May 2026 13:17:50 +0300") References: <20260429133928.850721-1-pratyush@kernel.org> <20260429133928.850721-11-pratyush@kernel.org> Date: Mon, 18 May 2026 19:04:53 +0200 Message-ID: <2vxzjyt08x8q.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 Sun, May 17 2026, Mike Rapoport wrote: > On Wed, Apr 29, 2026 at 03:39:12PM +0200, Pratyush Yadav wrote: >> From: "Pratyush Yadav (Google)" >> >> Methodology >> =========== >> >> Introduce extended scratch areas. These areas are discovered at boot by >> walking the preserved memory radix tree and looking for free blocks of >> memory. They then marked as scratch to allow allocations from them. This >> makes KHO more resilient to memory pressure and allows supporting huge >> page preservation. >> >> Since the preserved memory radix tree mixes both physical address and >> order into a single key, and does not track table pages, it is difficult >> to identify free areas from it directly. Walk the tree and digest it >> down into another radix tree. The latter tracks blocks of >> KHO_EXT_SHIFT (1 GiB as of now) granularity. Then walk the digested tree >> and mark the areas between the present keys as scratch. >> >> Signed-off-by: Pratyush Yadav (Google) >> --- >> include/linux/kexec_handover.h | 1 + >> kernel/liveupdate/kexec_handover.c | 148 +++++++++++++++++++++++++---- >> mm/mm_init.c | 1 + >> 3 files changed, 133 insertions(+), 17 deletions(-) >> >> diff --git a/kernel/liveupdate/kexec_handover.c b/kernel/liveupdate/kexec_handover.c >> index 1a04e089f779..c2b843a5fb28 100644 >> --- a/kernel/liveupdate/kexec_handover.c >> +++ b/kernel/liveupdate/kexec_handover.c >> @@ -840,6 +857,120 @@ static void __init kho_reserve_scratch(void) >> kho_enable = false; >> } >> >> +#define KHO_EXT_SHIFT 30 /* 1 GiB */ > > arm64 does not necessarily use 1G gigantic pages and worse, it can have 2 > gigantic hstates. > > I think this should take into account what actual gigantic page sizes are > in use for the general case. This has nothing to with the gigantic page sizes. This is simply the granularity at which KHO looks for free blocks. Making this larger means less memory usage and better performance at the cost of amount of memory recovered. Making this smaller does the opposite. I picked 1G because it "feels" the right balance. Mostly gut feeling without real science behind the number. I can make it smaller or larger if you'd like. -- Regards, Pratyush Yadav