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 9ECB83A759E for ; Wed, 13 May 2026 07:50:48 +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=1778658648; cv=none; b=UXc+M35EoFXC7i0MEgRBH7tAx2w9gpDgtJ2a9YnPbt6n37aV1yW2Qb1+qHGvliEvhH6FGOinkD6ZkbjigqF9jWXJOseQR9KObHVo4nWUR85yQyO3UetHxZw/PpSVPLuZO+ywyuoy5BeKJEBYePPZDOR2wWIOc47Oc1I3XCp4ydo= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1778658648; c=relaxed/simple; bh=MCQeJ5Iv131m6kkGCuiJh8lRJbCMXYg1egO+kK3uzhs=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=tFMfHWxXO0MN40bsKHPzj6T1DjWi5w/UwFbXoR5vdUh4rR6PwO6JkaG3rmT532wG0V7ZanUa0QjP/lGk6Shzmm7zRuSjiRYYKimLugb+CMZsx/4Nu/bYSt9C8srZQJo/EtgFqAKMBfpQg9/IPYxoWEJdGqhh+ZBjpnhKMhD1mnk= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=Y8tu24O4; 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="Y8tu24O4" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 54A0EC2BCC6; Wed, 13 May 2026 07:50:43 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1778658648; bh=MCQeJ5Iv131m6kkGCuiJh8lRJbCMXYg1egO+kK3uzhs=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=Y8tu24O4/8Mdg4dQoG8Q12JtRpcMuK9ZwwlE5pj6eCnqgKc/jmkwugKBpoKzB3hGa o+Rs7Q65GsAMFWDYtrgpUEIBoViTy2abAmFwlbZVlcRVeWDxIMKO6kKVJWy6lBX8gL Ce+v2ddB1S/xm3KKhsCZii6w+nUWH1lQGa4KIZbHleuemxRBt/oNQHjphVdbsBZPuP N6L4K76HmOhHk/uk9nlLwi7FV65i5CRLCs+zcFlMCEwrfoJYm1i7mcjXvqCdzIvEK/ 5fr6mgjDcLiqLhamJaxAobs7Og6yey+bl7vX5pVJO+aaZIkg83JpIvBwKossxCoLjX O5T//PvVAtihg== Date: Wed, 13 May 2026 10:50:40 +0300 From: Mike Rapoport To: Pratyush Yadav Cc: George Guo , pasha.tatashin@soleen.com, graf@amazon.com, jasonmiu@google.com, ran.xiaokai@zte.com.cn, akpm@linux-foundation.org, linux-kernel@vger.kernel.org, kexec@lists.infradead.org, linux-mm@kvack.org, George Guo , Kexin Liu Subject: Re: [PATCH 1/1] kho: fix KHO_TREE_MAX_DEPTH for non-4KB page sizes Message-ID: References: <20260509024415.33190-1-dongtai.guo@linux.dev> <2vxzcxz2dybi.fsf@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2vxzcxz2dybi.fsf@kernel.org> On Mon, May 11, 2026 at 12:40:01PM +0200, Pratyush Yadav wrote: > On Sat, May 09 2026, George Guo wrote: > > > From: George Guo > > > > KHO_TREE_MAX_DEPTH is calculated as: > > > > DIV_ROUND_UP(KHO_ORDER_0_LOG2 - KHO_BITMAP_SIZE_LOG2, > > KHO_TABLE_SIZE_LOG2) + 1 > > > > For systems with 16KB pages (e.g. LoongArch), this gives a depth of 4, > > As of now, we only support KHO on x86 and arm64. Support for other > architectures is not there. Are you working on supporting it for > LoongArch? What is your use case? arm64 can have 16k pages, but ... > So based on this, looks to me that the 5th level table won't ever go > above index 0 and the 4th level is enough to represent all possible > keys. ... as it looks like your math is correct, I'm going to drop the patch for now. > -- > Regards, > Pratyush Yadav -- Sincerely yours, Mike.