From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id D6B80C282EC for ; Tue, 11 Mar 2025 13:41:34 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 04269280003; Tue, 11 Mar 2025 09:41:33 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id F33A4280001; Tue, 11 Mar 2025 09:41:32 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id DD500280003; Tue, 11 Mar 2025 09:41:32 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0016.hostedemail.com [216.40.44.16]) by kanga.kvack.org (Postfix) with ESMTP id C10E8280001 for ; Tue, 11 Mar 2025 09:41:32 -0400 (EDT) Received: from smtpin23.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id 67868121EB2 for ; Tue, 11 Mar 2025 13:41:33 +0000 (UTC) X-FDA: 83209382466.23.DC5D2E4 Received: from mail-ej1-f43.google.com (mail-ej1-f43.google.com [209.85.218.43]) by imf14.hostedemail.com (Postfix) with ESMTP id 3125110001F for ; Tue, 11 Mar 2025 13:41:30 +0000 (UTC) Authentication-Results: imf14.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=jijZ5oc7; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf14.hostedemail.com: domain of richard.weiyang@gmail.com designates 209.85.218.43 as permitted sender) smtp.mailfrom=richard.weiyang@gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1741700491; h=from:from:sender:reply-to:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=TueZFVSlfkUTp0jdNfdYcZQNu83RAWuxPbzRk33Y34A=; b=ZXdvPyt/7USYkKq4X7oI1HZ+CIzPc/GqNnJkHoqJ4womdl8GnnlivCbNG/iYsVgWyrsV16 X2WcAlvo/16IpihJl25vW2SYzwK3Pp1NYDU/8TRvHuMcXXyhdEJNYTVlmYuX5Zua/TUJDK vmul2qvbdqlWXQ3lcO4eVKib0tN21X4= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1741700491; a=rsa-sha256; cv=none; b=7YgDJ99YfofgWBwbFF2cwXDxiAp1GCCNr/XEhTci8IEz/MZcvgHsdVy4AHraOqGk/2QQlu EYuJkmis0Pi1Wmo/mXQ4H1iXORB0rEPm3tvGbE2/EZLktVFbZ2rOlx7k74/5esxK40YliR 5xd0k1rMld4rQTVkWvx+QO+3gFB2MKc= ARC-Authentication-Results: i=1; imf14.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=jijZ5oc7; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf14.hostedemail.com: domain of richard.weiyang@gmail.com designates 209.85.218.43 as permitted sender) smtp.mailfrom=richard.weiyang@gmail.com Received: by mail-ej1-f43.google.com with SMTP id a640c23a62f3a-abbd96bef64so887408366b.3 for ; Tue, 11 Mar 2025 06:41:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1741700489; x=1742305289; darn=kvack.org; h=user-agent:in-reply-to:content-disposition:mime-version:references :reply-to:message-id:subject:cc:to:from:date:from:to:cc:subject:date :message-id:reply-to; bh=TueZFVSlfkUTp0jdNfdYcZQNu83RAWuxPbzRk33Y34A=; b=jijZ5oc7/GpDq2PlsjS8VGgw8w8DG2zgRv8wOG8stpth3MslDx2venyHr2J88d5Qtv Qg0hsr0wo5yJNt/nQhpgInGrd++sb/vInvP/CC9ZEokyXE5+tHBhbhbrJu/H4UU+IhUL tA5aOxV3omNlUiSKzSvHCZmslf55rcXALWIouMutGVWF/ymmyk+Z19b0ywgwq21NkJ6O kljPOjmF0dfsYY7NZE0Ck1U429YMM7SOvgNdazm6tsKy4WTzjOsnWmMvLUoCDRlnliK0 7C426XgXTxCR5Tnrw8n3s2fqP2SGdyspm5ukDSAga5JUUa72SFErxpWtG6+B1y1lkxdE 0TdA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1741700489; x=1742305289; h=user-agent:in-reply-to:content-disposition:mime-version:references :reply-to:message-id:subject:cc:to:from:date:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=TueZFVSlfkUTp0jdNfdYcZQNu83RAWuxPbzRk33Y34A=; b=ChXAZGPeEZ1AR4aUc7nZhT+mThZInBuReQc6ecyTkvzcn9lgSDiamfsEqg9mVnSMob Ey2Pr0h31Ld4BN8rQYbgMJjEK+xfNDAmj5TRTYVmpfNK+BA2oY8ME3jMBtHdVLHH/lbi +NzErNFkC+GNPMwLNY3xgUTabbEAXqQ6sAUQtk/hzddSysbDEqC+bjj7Z3k3CMQWvuu+ KFZt2PTR9vqAiHh9307m91zMz3KysUDu3wtjPxaTSPGiHmwQ6DQ3E/q2bKq+39f8WK26 ux0r6fD3djJYGJW9L806X6ZtJ7sDTgI/OKx5AEQfh94dW3JK+lLR4/2exD+W0psWwmgE K88Q== X-Forwarded-Encrypted: i=1; AJvYcCULthZ5oilfZnhPGfzevAuh0rNe8sdnZgLMvgeGn6xDh/BKyJpF80/HZYcFMsanl0krpueHIRxTSg==@kvack.org X-Gm-Message-State: AOJu0Yy0PleThw3L7JUW4CacQgk4x5vLl2ndS4Lo2jFBA9K+FK33LdtW lw5gCN8FEYGQNvLaxMZPtfPi+nxegzETlmvsXnGjaeJQfiNdHm0H X-Gm-Gg: ASbGncuoqenp0g3Kx0OMqYd1E7fiuWRfTB6Dle1cGd/iP02yan30Ndt7aXptaZxRgi1 BL4E2N9f7VKJgbvHiXHFdSpBlyOOcvldGf8BGuFh9WD5sLqcC2FfBmn1D5eupmEZYStMixbM3oO iHYSZ8Qut+M4GEYPVXZuvrLkIdgG1piOCjfUPPB1S3HgMEWq6FCDUBiFQ1+OIu2bC+oPyfFd9cu pJtV/QCC3IA463dVLt9m66AiYz+b0yNkuzzB2yS1s+rJaAIUiDRnUWIl2ZiQ0Gedjyzsf63kFx3 qAbdZfLlWidNsBfE8Qy1PtscyxsUuI/Py4thx/Gcy1PstrHtJgqqYxg= X-Google-Smtp-Source: AGHT+IEqvcT3nUuyCclAJyMA5I1jSzcLHsXRqFYyLbC3aVoohYneT0bwBO9KyAHB0hhKMZdf6pm4uw== X-Received: by 2002:a17:906:6a07:b0:ac2:c75d:f30a with SMTP id a640c23a62f3a-ac2c75dfff9mr258917866b.37.1741700488456; Tue, 11 Mar 2025 06:41:28 -0700 (PDT) Received: from localhost ([185.92.221.13]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-ac287653d1esm481132766b.125.2025.03.11.06.41.27 (version=TLS1_2 cipher=ECDHE-ECDSA-CHACHA20-POLY1305 bits=256/256); Tue, 11 Mar 2025 06:41:27 -0700 (PDT) Date: Tue, 11 Mar 2025 13:41:26 +0000 From: Wei Yang To: Mike Rapoport Cc: Wei Yang , linux-kernel@vger.kernel.org, Alexander Graf , Andrew Morton , Andy Lutomirski , Anthony Yznaga , Arnd Bergmann , Ashish Kalra , Benjamin Herrenschmidt , Borislav Petkov , Catalin Marinas , Dave Hansen , David Woodhouse , Eric Biederman , Ingo Molnar , James Gowans , Jonathan Corbet , Krzysztof Kozlowski , Mark Rutland , Paolo Bonzini , Pasha Tatashin , "H. Peter Anvin" , Peter Zijlstra , Pratyush Yadav , Rob Herring , Rob Herring , Saravana Kannan , Stanislav Kinsburskii , Steven Rostedt , Thomas Gleixner , Tom Lendacky , Usama Arif , Will Deacon , devicetree@vger.kernel.org, kexec@lists.infradead.org, linux-arm-kernel@lists.infradead.org, linux-doc@vger.kernel.org, linux-mm@kvack.org, x86@kernel.org Subject: Re: [PATCH v4 02/14] memblock: add MEMBLOCK_RSRV_KERN flag Message-ID: <20250311134126.xfjdq6sq7jtcotck@master> Reply-To: Wei Yang References: <20250206132754.2596694-1-rppt@kernel.org> <20250206132754.2596694-3-rppt@kernel.org> <20250218155004.n53fcuj2lrl5rxll@master> <20250223002229.xuk6xlp23zr72hkc@master> <20250310095124.pa7dwgqhxglqrfes@master> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: NeoMutt/20170113 (1.7.2) X-Stat-Signature: fpyyw1epw3zen816xy7qy8sb4uocm9hy X-Rspam-User: X-Rspamd-Queue-Id: 3125110001F X-Rspamd-Server: rspam04 X-HE-Tag: 1741700490-136393 X-HE-Meta: U2FsdGVkX1/VKqPpk/3YvlLgAIIYLnartGUHu21xq+WzHwPWiMK8BKTYEk2OyN/vcFf3MsekEmZs7qeRKCx7Klkh8XviO3DYZWU8xk4bCmGGdwyLdxBjUbmPGi/DiyvI+4BecJxsLDNa2EV81npEXBT5lCpRjZ9fncqDRYdjI6Taz+yCHSZ2sUDDToznhYFOg53I4p9noEdO8QKoCXHed2PMUQJFEVrsJ2JLTVVXImJuGrYzQEZtVNum2vSej9QX2J4rvmVCY8gUSlTyCDGpG4YrkYlYSi50ZqyzRG3R98VGRqsTt8KUew64MkXVkqZ9VZCWaUIhnGCM0mCu7sOuyGLJEGog9yybtelV+K8qjdM4Igf1ocfWXYbhezXybrnZZV3HyQfQvdYTUj3wMmXD9cDBaH016s18Gy+0DEGqbGU67wI18CsbywgFaKQZUuXdeg39Vexi/H3cDVOo/IHxEooDs6kSuRGohRPMnjoBOz9L4kuAFauD8uQGU3PSf4djiCujTlVSjnM4wwlj9kETVbbNucQyvXKs7vkjNE3unsf3f+7Pjaxfp1fL/m39D7HrI8874R2rQGfjzVmtzTt1+mlWJ4Bu2c2FtPCF9bZkHE/gBrTtHMGdzVimg6zQdNJ3Hb6V7a7aIRJLDnoXqRGikoZmmdrfwlf5ICcVCFrpfJNF44tQAi8pVXa2H82zkOOKd64s7Jmr0aOd5iUf6DUyK1E7V/ngGm7R4yp0UnDg20UKI9UKZ/c+2GNxbw+0ysaxjFlMUh2VJL+C5JfatSNLoiBSiL5OM3rwpnfEgRLWCz6mgvDb3vcmdRlgG/yVhN9x7rinO1yCWC3G/DVj8ZRMSNhzhex/7xT/GBDqzv9UGE3bHA4q909eH/aL4RRUVIeLzkrVCjSy8klmCpPhvlcT/5Ez7keeGBgizn6wR6eQYJ3Lf5sHAnZzmxPcuD0m3eeq5bVjHRPx7KGivwC4Rvo RfbtOJ7e cR1DMXJ57yPvWe3ndxbmJ1RhNG9QA+HS/B/RKkmMTDjX2YibgxB9eULibPjkOObue98E1CzeCh9lIuYJ5H70Qtvzzrl04sTTkXukmZ1sUUvo3F6f0jEa4tbhbl8uhGD4i6vhAbRSv9c8Vi+2B9cfOInnvRpz5+jMQWfBrPASb479f+T66ujHNqe9RSXNjS0lPjY8ATtR8c3y++Ke8KDyMARdpJApGJ/IgL8/EYMX++K5l3INpZArV2nFauvvyHen7nD9JZnmkQ8AjUGOuCgSPjc5qr9BgIeNAUFd9hSJTxwN3XYw/n5lYXf6OezIlJuYB34DxQe/spcyt1evCHHz3h9LFFBJeEUP69zyY0Co11osnTod5qC1BgXm8FViKYQ7pm98+ThNhNCKnSxN9qf1A4kYpc3W7mx1YQyh2jgWgKkzfVoYYVDUeqaC9t3PFEjmc2x3gpVPyiOnU+aqjxWtOl3YN9t8YCmJK+oz1ijZLSau0MDMQ5W+ndKB1sIpOUEzZiqu6F4JhAoHEaIvfS8pfmGSVs02msCdmLutlmnbkxAsqiUjaxDmndX7j2qMmex9A6bGQW/mHVAwcIOrzhjXXfm2YR0avgYhp0BxJCjdu7A73LJi+VOIuveic1bYolBenT7RKt/CLJOGLKv83EG0fpwv4rUNO16MK5v1jBlgmO+VybeumGBFw3I0pRzlDVf4fTxSucjMDvOo275es2blM+MRyThZV3ky9IMH7XDy70sub5mppfg1WBdMh6Q== X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: On Tue, Mar 11, 2025 at 07:27:23AM +0200, Mike Rapoport wrote: >Hi Wei, > >On Mon, Mar 10, 2025 at 09:51:24AM +0000, Wei Yang wrote: >> On Sun, Feb 23, 2025 at 12:22:29AM +0000, Wei Yang wrote: >> >On Wed, Feb 19, 2025 at 09:24:31AM +0200, Mike Rapoport wrote: >> >>Hi, >> >> >> >>On Tue, Feb 18, 2025 at 03:50:04PM +0000, Wei Yang wrote: >> >>> On Thu, Feb 06, 2025 at 03:27:42PM +0200, Mike Rapoport wrote: >> >>> >From: "Mike Rapoport (Microsoft)" >> >>> > >> >>> >to denote areas that were reserved for kernel use either directly with >> >>> >memblock_reserve_kern() or via memblock allocations. >> >>> > >> >>> >Signed-off-by: Mike Rapoport (Microsoft) >> >>> >--- >> >>> > include/linux/memblock.h | 16 +++++++++++++++- >> >>> > mm/memblock.c | 32 ++++++++++++++++++++++++-------- >> >>> > 2 files changed, 39 insertions(+), 9 deletions(-) >> >>> > >> >>> >diff --git a/include/linux/memblock.h b/include/linux/memblock.h >> >>> >index e79eb6ac516f..65e274550f5d 100644 >> >>> >--- a/include/linux/memblock.h >> >>> >+++ b/include/linux/memblock.h >> >>> >@@ -50,6 +50,7 @@ enum memblock_flags { >> >>> > MEMBLOCK_NOMAP = 0x4, /* don't add to kernel direct mapping */ >> >>> > MEMBLOCK_DRIVER_MANAGED = 0x8, /* always detected via a driver */ >> >>> > MEMBLOCK_RSRV_NOINIT = 0x10, /* don't initialize struct pages */ >> >>> >+ MEMBLOCK_RSRV_KERN = 0x20, /* memory reserved for kernel use */ >> >>> >> >>> Above memblock_flags, there are comments on explaining those flags. >> >>> >> >>> Seems we miss it for MEMBLOCK_RSRV_KERN. >> >> >> >>Right, thanks! >> >> >> >>> > >> >>> > #ifdef CONFIG_HAVE_MEMBLOCK_PHYS_MAP >> >>> >@@ -1459,14 +1460,14 @@ phys_addr_t __init memblock_alloc_range_nid(phys_addr_t size, >> >>> > again: >> >>> > found = memblock_find_in_range_node(size, align, start, end, nid, >> >>> > flags); >> >>> >- if (found && !memblock_reserve(found, size)) >> >>> >+ if (found && !__memblock_reserve(found, size, nid, MEMBLOCK_RSRV_KERN)) >> >>> >> >>> Maybe we could use memblock_reserve_kern() directly. If my understanding is >> >>> correct, the reserved region's nid is not used. >> >> >> >>We use nid of reserved regions in reserve_bootmem_region() (commit >> >>61167ad5fecd ("mm: pass nid to reserve_bootmem_region()")) but KHO needs to >> >>know the distribution of reserved memory among the nodes before >> >>memmap_init_reserved_pages(). >> >> >> > >> >I took another look into this commit. There maybe a very corner case in which >> >will leave a reserved region with no nid set. >> > >> >memmap_init_reserved_pages() >> > for_each_mem_region() { >> > ... >> > memblock_set_node(start, end, &memblock.reserved, nid); >> > } >> > >> >We leverage the iteration here to set nid to all regions in memblock.reserved. >> >But memblock_set_node() may call memblock_double_array() to expand the array, >> >which may get a range before current start. So we would miss to set the >> >correct nid to the new reserved region. >> > >> >I have tried to create a case in memblock test. This would happen when there >> >are 126 memblock.reserved regions. And the last region is across the last two >> >node. >> > >> >One way to fix this is compare type->max in memblock_set_node(). Then check >> >this return value in memmap_init_reserved_pages(). If we found the size >> >changes, repeat the iteration. >> > >> >But this is a very trivial one, not sure it worth fix. >> > >> >> Hi, Mike >> >> I have done a user space test which shows we may have a chance to leave a >> region with non-nid set. >> >> Not sure you are ok with my approach of fixing. > >Wouldn't it be better to check for a change in reserved.max in >memmap_init_reserved_pages()? > Sounds better. Previously I thought we need to hide detail from user, but actually it is already in memblock.c :-) If you agree, I would like to prepare a fix. >> -- >> Wei Yang >> Help you, Help me > >-- >Sincerely yours, >Mike. -- Wei Yang Help you, Help me