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 AF990EB64DD for ; Thu, 27 Jul 2023 20:56:34 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 1B75E6B0072; Thu, 27 Jul 2023 16:56:34 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 140D46B0074; Thu, 27 Jul 2023 16:56:34 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id EFD556B0075; Thu, 27 Jul 2023 16:56:33 -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 E09F86B0072 for ; Thu, 27 Jul 2023 16:56:33 -0400 (EDT) Received: from smtpin11.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id AC2F68028A for ; Thu, 27 Jul 2023 20:56:33 +0000 (UTC) X-FDA: 81058600266.11.C887D6D Received: from mail-wm1-f50.google.com (mail-wm1-f50.google.com [209.85.128.50]) by imf24.hostedemail.com (Postfix) with ESMTP id 9CF0C180004 for ; Thu, 27 Jul 2023 20:56:31 +0000 (UTC) Authentication-Results: imf24.hostedemail.com; dkim=pass header.d=bytedance.com header.s=google header.b=GUuXheYW; dmarc=pass (policy=quarantine) header.from=bytedance.com; spf=pass (imf24.hostedemail.com: domain of usama.arif@bytedance.com designates 209.85.128.50 as permitted sender) smtp.mailfrom=usama.arif@bytedance.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1690491391; h=from:from:sender: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:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=ZuRgeT5VlstWJ8B1+I/x/Bo/hFhxlkd2kqhh5r6tMvo=; b=4hZZtZHC6+QP7RGv7VZ5Gqsb7imYjNau2J3xlZTGYsYKtsFI0e6pOeJzL8v3Db/bPmOeeJ 4x9Or/9v9xxbp5LSZdivfFAKK5Na/YFPa+SOiOYuW48o8zEyl7U5HObajHAoeNp6mCvfBK /hUnErTXI8WTOzt32VdfG+j4i5xSGzQ= ARC-Authentication-Results: i=1; imf24.hostedemail.com; dkim=pass header.d=bytedance.com header.s=google header.b=GUuXheYW; dmarc=pass (policy=quarantine) header.from=bytedance.com; spf=pass (imf24.hostedemail.com: domain of usama.arif@bytedance.com designates 209.85.128.50 as permitted sender) smtp.mailfrom=usama.arif@bytedance.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1690491391; a=rsa-sha256; cv=none; b=Wf+ouPKmff90Xl469s+wd8/PI28T8HzWHPeUx6329GkHfWSze0U7k79UsyzPC43cNSqRul R3qBOq/OSi6w3198+3OnwhJAw4BKl2IT8SxnygeqZFFaEy86SrWnzDhXwY8TZ/isRaupUl CcW1SrVF8P7SspQwfKMQ4E/xRhGW/jA= Received: by mail-wm1-f50.google.com with SMTP id 5b1f17b1804b1-3fbea14700bso14207155e9.3 for ; Thu, 27 Jul 2023 13:56:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bytedance.com; s=google; t=1690491390; x=1691096190; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=ZuRgeT5VlstWJ8B1+I/x/Bo/hFhxlkd2kqhh5r6tMvo=; b=GUuXheYW4WvNv7X7DW3/pE92+8S04jgSbsMYnMgR2VUJTShU2PWaO0ZxK8TRClpzMj ogBc/bRm4qV8UAWdqQ0agHWPjuBnm1aix6Ryr5V6JScupiSQzxYUzh9qpFPfkqTR9pvP puk28X+Q7mE47jIJ0qtFq9U7wGeDiLX8Vh7/2pM4AtKx6XnAyFFAlkZlVgge8Zfp+Y/5 Cou+oM4ac38To08oM9OdpR7YPba1PmtbjkNCCIqtDaTPBevew2eWbQV0c8m8K0NhfuJk 25/swSF/8/gvYAE9bw374d4sgIH7/UHFm/vjTzChhfMpXiStc+1orlo1yAvdsINUybUP 08Aw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1690491390; x=1691096190; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=ZuRgeT5VlstWJ8B1+I/x/Bo/hFhxlkd2kqhh5r6tMvo=; b=FYeZ/aOLqpjba4c3yqqCkDpCWSiFFy2NbpzxpdcV18JTFCyhUJTJhjolmZO0EuJsEy MhhlRAy+HQVta4B9gbg4MSelYxmcfF2V71iG7+pW4zXqgScrOXh1s9whCQFHwKJvtTDp P8VtwkGXDSG+NOVsW9JhHGO/a8sN7TxVsBTt2YdfgT+5TCM43DhAnW8YkJNKnaKy0rja SSaRsb78dRquLVsXMrCHg6td/QSdjDo6Tz2wDPhw7+3ObOxncNr09ayfCgrfyJLCt9gt irud52acDshsFlU9lvPL9eI9qx1PqLeTLnzRGb0VqTUYCrfuFGfxUnGoZN8M+P3UP3Xm oecg== X-Gm-Message-State: ABy/qLaiOv9nImDsUVmfj8LX2JsFHLrztS00tUaiQDRDHLSXUEm86VPh 3JwYVtHkJi9HyoPFS9JeF10Cbg== X-Google-Smtp-Source: APBJJlGs1jeeH1Eow3I3RdeLRBmy0ZNvAuNmUXCMigvkucMCAXAIQ1kbpSNECnd+OkRlHEmPYp3vcQ== X-Received: by 2002:a5d:6b8c:0:b0:314:e929:bcb9 with SMTP id n12-20020a5d6b8c000000b00314e929bcb9mr224952wrx.57.1690491390092; Thu, 27 Jul 2023 13:56:30 -0700 (PDT) Received: from ?IPV6:2a02:6b6a:b465:0:7e3e:db9e:70fa:9ccb? ([2a02:6b6a:b465:0:7e3e:db9e:70fa:9ccb]) by smtp.gmail.com with ESMTPSA id s18-20020a5d5112000000b00313e59cb371sm3065937wrt.12.2023.07.27.13.56.29 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 27 Jul 2023 13:56:29 -0700 (PDT) Message-ID: <383a72f7-b9d3-963f-e5fb-b0036376399e@bytedance.com> Date: Thu, 27 Jul 2023 21:56:28 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.4.2 Subject: Re: [External] Re: [RFC 2/4] mm/memblock: Add hugepage_size member to struct memblock_region Content-Language: en-US To: Mike Rapoport Cc: linux-mm@kvack.org, muchun.song@linux.dev, mike.kravetz@oracle.com, linux-kernel@vger.kernel.org, fam.zheng@bytedance.com, liangma@liangbit.com, simon.evans@bytedance.com, punit.agrawal@bytedance.com References: <20230724134644.1299963-1-usama.arif@bytedance.com> <20230724134644.1299963-3-usama.arif@bytedance.com> <20230726110113.GT1901145@kernel.org> <440d4a0e-c1ea-864b-54cb-aab74858319a@bytedance.com> <20230727043002.GA1901145@kernel.org> From: Usama Arif In-Reply-To: <20230727043002.GA1901145@kernel.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 9CF0C180004 X-Rspam-User: X-Rspamd-Server: rspam02 X-Stat-Signature: ow5z3quzpt7sk17jkgeokggqpg9a1ryn X-HE-Tag: 1690491391-858763 X-HE-Meta: U2FsdGVkX19mrSuRNC3/bnkx6ySf3q7Oe+y8zgyqzbHg/M9AsVMiXs5HybbWfyy5jRyUonxDMf+KWRlR5EZRFaB1xs/RE50rd5Yw6nGwzsW4ZeWIA1CsuovRGQlUmYvOvWgyTWaFOuFK70XBGJkeWXPFU5qZarDZ8/6ffMKlkPzPwczXZP41Vowi6bBi2fBfpWtmkjg1Ur9tIJIgZw0do2KS9mvIEXocKIDWr1JivArDY1uoz7wbMMcN60aHpZWNs9967ZTrzVIWx9c0o9an5a3TEdKHgQpOL6g+/iVsGh5m/NvszZitnoTrMldfrwi/j2qoc9/Ilhg+IOdFn+ZcbAQeeUFADgXg28LA/Ycqnoa55t7/NZeFoiPJZk7sNWRz1OTWtVnsSLHilNFYAv7jIYrmybGjtATKKUGYlNd//cRs8isAhdve6glMRrqRJd3dZvOcNdRLDvlTC33FEIMGmAI6zfe18ikRo4ANwBZuGznHi5e49HUaeTsyyhjdpTbSN9GmxJ5qjmKH8DLSCHY0pg2oEnezAhlpwVOM0GIkzk4MntSk6NeuhSdS22WUXGmSwjT4yhwO0uIG/14/Ad5zdWiRLDXFzz21YN7lgZhqTWzPuwL9gSa9MlpCX7udpbQHB9AHTJ/sYVil27KyHeD379/IOq/nwUC2tQqBOJU68BImIZlsl4kPS3+asOfyde4RpEHPhrSc+vgZswyngjPmjFuHiPYWj47X/hT7eLCliUKWmxEoZqlK3RdQ95awoo3hFsnYDTEy6+HSBinr2QDs9VKvb+Q3WCOzYpn0iCs1l5f4PHeNxUDB0mp8kjAZ06vlR2vBeyLT2AopmsT3l30aPlm77WVnK4B5CaAdFgf6BbdlcjKNVAWcRbcrObDEbNh4hxuDx/hpGYxa1hFlNRYUlLDK3zd+g5E8AazuGFdmAK+tvQavOO1gIS1YapnazbINAp5i2J4l8lAs3T/s3FB LFxkD+9J RLBfUYhtF7mD55qv9vlsRgzFqWnvPy1DCyiVHIMFvzNfCXZQLpUyKzCIErglTGxv1zoemdT5vAANcU+3Hd7/A84fWcX3cy1gTf8Ab8f5opVSnDP00+TszPwAdAZsIbf44IOUWkLaCJ/0RoH3wXXoWjMto7ZKwxEsafR33RIHqlE1N22GHXiNUQR5+gGneAhCH0APhAb36Y+ak4nJACjKw8TBhU9c6PB+MhOqnIZ1ZZ1JQiG9TNaE2hqXp0zvrTQqomc71csZLj6Lr0nJ7vtoRQvKu73Es/my2zTyJXCLPJCkSOszNLon6PrmwJ9PG2VkgJbV1pUFYlBSy/s9WFVnPg+3Eufu/Ha02IO4jrpbOZ0gb5qI744h6rPELflUROm3N/DQM46FoXe/tztpqsC6Jvgcicmm/61PHV+VJEnEZHPYK0IB4iZ7lat3ozZ2M6Ed+xowC9KLXW34JgShLlb1LQ2kVqByWXqOlEWQQFVPhWYwGxtn+DnX664t8a0i8YOKDcYfYPUyWnKtPK38VqgFpz1D0HWQ68q3ymIjNYfGdV4gXQH9chPy7r76fTw== 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: On 27/07/2023 05:30, Mike Rapoport wrote: > On Wed, Jul 26, 2023 at 04:02:21PM +0100, Usama Arif wrote: >> >> On 26/07/2023 12:01, Mike Rapoport wrote: >>> On Mon, Jul 24, 2023 at 02:46:42PM +0100, Usama Arif wrote: >>>> This propagates the hugepage size from the memblock APIs >>>> (memblock_alloc_try_nid_raw and memblock_alloc_range_nid) >>>> so that it can be stored in struct memblock region. This does not >>>> introduce any functional change and hugepage_size is not used in >>>> this commit. It is just a setup for the next commit where huge_pagesize >>>> is used to skip initialization of struct pages that will be freed later >>>> when HVO is enabled. >>>> >>>> Signed-off-by: Usama Arif >>>> --- >>>> arch/arm64/mm/kasan_init.c | 2 +- >>>> arch/powerpc/platforms/pasemi/iommu.c | 2 +- >>>> arch/powerpc/platforms/pseries/setup.c | 4 +- >>>> arch/powerpc/sysdev/dart_iommu.c | 2 +- >>>> include/linux/memblock.h | 8 ++- >>>> mm/cma.c | 4 +- >>>> mm/hugetlb.c | 6 +- >>>> mm/memblock.c | 60 ++++++++++++-------- >>>> mm/mm_init.c | 2 +- >>>> mm/sparse-vmemmap.c | 2 +- >>>> tools/testing/memblock/tests/alloc_nid_api.c | 2 +- >>>> 11 files changed, 56 insertions(+), 38 deletions(-) >>>> >>> >>> [ snip ] >>> >>>> diff --git a/include/linux/memblock.h b/include/linux/memblock.h >>>> index f71ff9f0ec81..bb8019540d73 100644 >>>> --- a/include/linux/memblock.h >>>> +++ b/include/linux/memblock.h >>>> @@ -63,6 +63,7 @@ struct memblock_region { >>>> #ifdef CONFIG_NUMA >>>> int nid; >>>> #endif >>>> + phys_addr_t hugepage_size; >>>> }; >>>> /** >>>> @@ -400,7 +401,8 @@ phys_addr_t memblock_phys_alloc_range(phys_addr_t size, phys_addr_t align, >>>> phys_addr_t start, phys_addr_t end); >>>> phys_addr_t memblock_alloc_range_nid(phys_addr_t size, >>>> phys_addr_t align, phys_addr_t start, >>>> - phys_addr_t end, int nid, bool exact_nid); >>>> + phys_addr_t end, int nid, bool exact_nid, >>>> + phys_addr_t hugepage_size); >>> >>> Rather than adding yet another parameter to memblock_phys_alloc_range() we >>> can have an API that sets a flag on the reserved regions. >>> With this the hugetlb reservation code can set a flag when HVO is >>> enabled and memmap_init_reserved_pages() will skip regions with this flag >>> set. >>> >> >> Hi, >> >> Thanks for the review. >> >> I think you meant memblock_alloc_range_nid/memblock_alloc_try_nid_raw and >> not memblock_phys_alloc_range? > > Yes. > >> My initial approach was to use flags, but I think it looks worse than what I >> have done in this RFC (I have pushed the flags prototype at >> https://github.com/uarif1/linux/commits/flags_skip_prep_init_gigantic_HVO, >> top 4 commits for reference (the main difference is patch 2 and 4 from >> RFC)). The major points are (the bigger issue is in patch 4): >> >> - (RFC vs flags patch 2 comparison) In the RFC, hugepage_size is propagated >> from memblock_alloc_try_nid_raw through function calls. When using flags, >> the "no_init" boolean is propogated from memblock_alloc_try_nid_raw through >> function calls until the region flags are available in memblock_add_range >> and the new MEMBLOCK_NOINIT flag is set. I think its a bit more tricky to >> introduce a new function to set the flag in the region AFTER the call to >> memblock_alloc_try_nid_raw has finished as the memblock_region can not be >> found. >> So something (hugepage_size/flag information) still has to be propagated >> through function calls and a new argument needs to be added. > > Sorry if I wasn't clear. I didn't mean to add flags parameter, I meant to > add a flag and a function that sets this flag for a range. So for > MEMBLOCK_NOINIT there would be > > int memblock_mark_noinit(phys_addr_t base, phys_addr_t size); > > I'd just name this flag MEMBLOCK_RSRV_NOINIT to make it clear it controls > the reserved regions. > > This won't require updating all call sites of memblock_alloc_range_nid() > and memblock_alloc_try_nid_raw() but only a small refactoring of > memblock_setclr_flag() and its callers. > Thanks for this, its much cleaner doing the way you described. I have sent v1 implementing this https://lore.kernel.org/all/20230727204624.1942372-1-usama.arif@bytedance.com/. Regards, Usama