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 47E2FC4345F for ; Sat, 27 Apr 2024 10:24:41 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 632976B007B; Sat, 27 Apr 2024 06:24:40 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 5E2E66B0082; Sat, 27 Apr 2024 06:24:40 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 4AA6F6B0083; Sat, 27 Apr 2024 06:24:40 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id 2EFA56B007B for ; Sat, 27 Apr 2024 06:24:40 -0400 (EDT) Received: from smtpin17.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id 37A7DC07CB for ; Sat, 27 Apr 2024 10:24:39 +0000 (UTC) X-FDA: 82054927878.17.F27D67D Received: from mail-wr1-f52.google.com (mail-wr1-f52.google.com [209.85.221.52]) by imf04.hostedemail.com (Postfix) with ESMTP id 6CD1F4000C for ; Sat, 27 Apr 2024 10:24:37 +0000 (UTC) Authentication-Results: imf04.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=iAqgF6tf; spf=pass (imf04.hostedemail.com: domain of skseofh@gmail.com designates 209.85.221.52 as permitted sender) smtp.mailfrom=skseofh@gmail.com; dmarc=pass (policy=none) header.from=gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1714213477; 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=l2oCs009FNTFic+6/Bn8POOKtUyuT0t/au2Vi8nWiyk=; b=F9qg2fyNgHE8pYwtXKHOsdvqb0yKPVbpEQD+mmdI0SepHlHdiwatsqPUoMfHRoDHfHLrVg ff0HIywASPOLlUAjnPxOvYfNNzdcCdDP/zgE3Ky3j3/Qd5YrR3/7f12wfoarg3j31Ev8Kj iCA9I1s4yvpqPdfP9s/st87JUEiUBrk= ARC-Authentication-Results: i=1; imf04.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=iAqgF6tf; spf=pass (imf04.hostedemail.com: domain of skseofh@gmail.com designates 209.85.221.52 as permitted sender) smtp.mailfrom=skseofh@gmail.com; dmarc=pass (policy=none) header.from=gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1714213477; a=rsa-sha256; cv=none; b=jyzD2BT/zBVVZ3CjHtFJbolhnWIVZlMFVxvkQRYbG753u3IEa88YkmbKCOQrWwalnx3DWI yH0h576UDb3j5A1VMYx+QtmSOkMkGM8AIT06s6sOdnn/AYmcvC6Nv8+v/1ctDXH/w9ITRY E1j+K+E5vaedUR/rYre8zsRpSReGJZg= Received: by mail-wr1-f52.google.com with SMTP id ffacd0b85a97d-34c0f5f5cd0so2071654f8f.2 for ; Sat, 27 Apr 2024 03:24:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1714213476; x=1714818276; darn=kvack.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=l2oCs009FNTFic+6/Bn8POOKtUyuT0t/au2Vi8nWiyk=; b=iAqgF6tfFOaBgQcaQE8KEPKiO9Yg1rQbtOiBKBNoN/l8JOqM9po37mc6bzDCts95+i WcI47GfJI69UfLLFBfuggYea6ioWp2xG5PaNhYgk5gfBtoB/XTF16+BjxfQ/IuzK+Nhl G8eCbzFzkWNFCpFb23StJMWBI9RTtRcvPEAP7sMPNbmfsm5GaXXa/mcxbVPpElyj0R2q e4QjHZW7VTYdSh/bGYuHORJnULhoVzebW39sz5dFkOpqzfG7bXMHGRL6rXcoeJt5tczL zPKEB6vDfDcJ6nkbbd8+c/MOD+UBx0ADPCIZ0OP5+OFWxA33iDsBNvLDIr8hpdyhRvfo dJ9A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1714213476; x=1714818276; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=l2oCs009FNTFic+6/Bn8POOKtUyuT0t/au2Vi8nWiyk=; b=riKWn0QvzuqjhQ5CyvC/6hUGgkNPM3tFshOgF7alcalqocksEqi4r9Kjy2qchLH/bu 8bORQheFMBO+Ik0L8gbMwBtv5HN5GLT58HXN2xGvlRTceIcuBVzZyAr7sRvSJgzm7i9Y d1zt1UOjQf21YGDLFM8KDOVD7EKGPrQg/wrcwk1oSEpmEPXO3rFIi2zDTGJycvhy8HzS YFKx6jB4JRaqkJZVNvmM8v1H1e925CrUOvMjpj62SCrxVwslmqaNaAjsEHfs3JFubjCd rTBamY+dHlgTNdLp1OXJQo/dz9yu7gLDfNhpVWJGqwGKsijR/KX2kMLGEucYQLqutt7S tlVg== X-Forwarded-Encrypted: i=1; AJvYcCX1HRBWObKPP3TLrYhOC6oJp7KfXHQ+a+Dwtk4XOfdbew+bpLYOL0nxNHPUTO+WMGvKc0b20CfMgEEin7qQqe6eLi0= X-Gm-Message-State: AOJu0Yz18DBG4dA55bWTbIiz8PqR2rfFsBK5LdxQiHfLr67Bevb0iIwD bsJsqFFMPDyRsILhdJoAcfg8CUg3a9AD05Nc/rF3mPPpkOn/TVaw7badRI7QOVaMlw4nQrmzUD+ iRlm6NccoERyVUu6h05nt4cSOdGE= X-Google-Smtp-Source: AGHT+IEpODtrHOY9y5XiFObx7A01K4CsUREu8unoiWY37KTSNvNOkosI6RMW7bnuRGPZWGVYRcGG1WgD5YuRs0mx3mU= X-Received: by 2002:a5d:58d8:0:b0:34a:1cc5:ee0c with SMTP id o24-20020a5d58d8000000b0034a1cc5ee0cmr312655wrf.26.1714213475436; Sat, 27 Apr 2024 03:24:35 -0700 (PDT) MIME-Version: 1.0 References: <20240416120635.361838-1-skseofh@gmail.com> <20240416120635.361838-2-skseofh@gmail.com> In-Reply-To: From: DaeRo Lee Date: Sat, 27 Apr 2024 19:24:23 +0900 Message-ID: Subject: Re: [PATCH v2] memblock: add no-map alloc functions To: Mike Rapoport Cc: robh@kernel.org, saravanak@google.com, akpm@linux-foundation.org, devicetree@vger.kernel.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org, Daero Lee Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Stat-Signature: 9q6sjhjez4q6gpmgghmzbd8qkwjhymju X-Rspamd-Queue-Id: 6CD1F4000C X-Rspamd-Server: rspam10 X-Rspam-User: X-HE-Tag: 1714213477-867253 X-HE-Meta: U2FsdGVkX19wdko/IL03SKwdxCubfxwMM4GPnVpNrKibFTeOVcl9utg86mgZtrO0sfvhWc4Wdvj9XBiIfEgOr87UDLXSrU6EKJEzpldkBQwElO1X/AZzcBudx0Se+LrloO+CTrWxHrnvEOPYzvYZ8Yq27zHjjJHj0TOuI2eg2anuF1nygfuhL6G2HKi7u6kD3uspFVLDjJHbogjBpLyCrFaAopNhucXNCwugDfg/A8LSoq9JbbKR23dFtl0IOJsag+BCdxIblykjAbKrzNQlg6jr/rX/RIH0Dzc0jzk2MMUdXYX+WDTROCDORnJQbefJP4hmhHXMyDwWmgyeQYVY5oG/x8UrBJhVPo8zNrGMktdwXiP2zvsmf15/3u7Wk5bAokUYbAhL1/3VbDK7+ZXGKnzMDo6G6cRBcdkd6w4xh+0s4wht32oRi9CfB2EsaANDWgrN2pbIPONwFVP2k+fuJVkwmD4n2FRdpChSuKjIkm52z0h4mRmcvCGmgcSkifmo7EsqlcBHJfJnqZ80SgjS9zdgbYthWOivdyRb7isAYpZ8tBLg29Y/OxFNh0+FL3c09pB4UpeO/LTG6YDnVdCAuGqEmopbASnQLqAggAMy/YQ1geoChVP9hmpPjOZc6g4CO+Th7pzCMzJaQDFL1xT4L1Sg6upM8T76o7yHzaclo11jnqcmgf8i6FpFIHK2S2vnbNQ8Jw4ugq5j4ZsX6lciSfZhjZmjTRxBM5AqCJzm9/o6LU7n697r0AmtYJFgoG9gG93YygBH/OIqAnhK3KXIcOQGhEW4v+6xcQejDbgTzs0fuLtlj2M7aVBy8ZxeriCthSNsBe77CqdTCFI40KeyF1ZNikBHwPytNlgRDPWOQnGedDWo27kDr3ONGK53uTaHaQCEi90RJ37aLmMdXRevo+zUl4jxH8a5GGghNvdRI6fkUIeZbbqHK/pZrECkvRhfF/j5zYwzH8jJFLTJXcp nhNP7Qjj 4aJz9u3JSRpybToMnpuJgoE2CmfBp8+X5u6t12yL1k4bHrcN+EJNGY3omTRUzqdu72qiIJYutYxRtrPcAqxj9LAkG1eJwfkIrX1hrOt+DtRgaKtoEVN13kluPzqAldG4Jsom/JzF5drrzD7Pm8J71HMw75pXB2b2QERm2pcSoSu+IB0d2g1NkVBdhD/9TSwZIa6TiTQI0Q2ankXpKPIMu+EAbMy/VQba94MU8zcg9n5KkHcMdr4inG1qIP2YV1FzdPtz70Z8NX1fTW/63kwa8LhGaca1xtXfRh9NsERVpDdRdrpJoevbS5yGDikmOelNBVVYfzIS/UMfgkKwp4yjTP+aFbbjD/KXoXBUxhFrrzikNlmcH/Jr0uDVbx6WsaB9trZs3/C/U5Q68DGek5ltb+cYkwT5ZqS2Wvi9PRXXX14EdEavrIJhV5LeCaQ== X-Bogosity: Ham, tests=bogofilter, spamicity=0.007054, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: 2024=EB=85=84 4=EC=9B=94 27=EC=9D=BC (=ED=86=A0) =EC=98=A4=ED=9B=84 5:50, M= ike Rapoport =EB=8B=98=EC=9D=B4 =EC=9E=91=EC=84=B1: > > On Fri, Apr 19, 2024 at 10:59:52AM +0900, DaeRo Lee wrote: > > 2024=EB=85=84 4=EC=9B=94 19=EC=9D=BC (=EA=B8=88) =EC=98=A4=EC=A0=84 10:= 46, DaeRo Lee =EB=8B=98=EC=9D=B4 =EC=9E=91=EC=84=B1: > > > > > > In memmap_init_reserved_pages, we mark memblock.reserved as > > > PageReserved first and mark the memblock.reserved with nomap flag > > > also. > > Sorry. This is my mistake. 'memblock.memory with nomap flag' is right. > > > > > -> Isn't this duplicated work? (If we add no-map region to > > > memblock.reserved 'and' mark in memblock.memory..) > > > So, I think that for the no-map region, we don't need to add to the > > > memblock.reserved. > > > This is what we do now in early_init_dt_reserve_memory. the nomap > > > region is not added to the memblock.reserved. > > > > > > In early_init_dt_alloc_reserved_memory_arch, if 'nomap' is true, we > > > mark the memblock.memory region as _NOMAP. And if the return value > > > 'err' is not zero(which is '-ENOMEM' from memblock_isolate_range), we > > > free the region. > > > - 'nomap' is true -> memblock_mark_nomap : success -> not free the re= gion > > > > > > : fail -> free the region > > > And it can be said that we add the region to the memblock.reserved > > > using memblock_phys_alloc_range and if the region is nomap, then we > > > can free the region from memblock.reserved. But is it necessary to ad= d > > > it to memblock.reserved? We just need the region in memblock.memory t= o > > > mark nomap. > > > > > > So, here is what I think: > > > - reserved-memory w/ nomap region -> mark only to memblock.memory > > > - reserved-memory w/o nomap region -> add to the memblock.reserved > > NOMAP and memblock.reserved are semantically different, and at makes sens= e > to have a "reserved nomap" node in fdt recorded in both memblock.memory a= nd > memblock.reserved. > > memblock.reserved represents the memory that is used by firmware or early > kernel allocation, so reserved memory in fdt should be reserved in memblo= ck > as well. I believe it's an oversight that early_init_dt_reserve_memory() > does not call memblock_reserve() for nomap memory. > > NOMAP is a property of a memory region that says that that region should > not be mapped in the linear map, it's not necessarily in use. I agree that the NOMAP region should be added to memblock.reserved. So, I think we need to clean-up memmap_init_reserved_pages, because in this function we call reserve_bootmem_region for memblock.reserved and memblock.memory with nomap. We don't need to call reserve_bootmem_region for nomap. Regards,. DaeRo Lee