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 621A3C4345F for ; Sun, 28 Apr 2024 06:35:06 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 7A3B96B007B; Sun, 28 Apr 2024 02:35:05 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 7470B6B0083; Sun, 28 Apr 2024 02:35:05 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 60E936B0085; Sun, 28 Apr 2024 02:35:05 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0010.hostedemail.com [216.40.44.10]) by kanga.kvack.org (Postfix) with ESMTP id 443FE6B007B for ; Sun, 28 Apr 2024 02:35:05 -0400 (EDT) Received: from smtpin28.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id 692491C123D for ; Sun, 28 Apr 2024 06:35:04 +0000 (UTC) X-FDA: 82057978128.28.F4742DB Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by imf09.hostedemail.com (Postfix) with ESMTP id B3E6014001C for ; Sun, 28 Apr 2024 06:35:02 +0000 (UTC) Authentication-Results: imf09.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=NFnNagcm; spf=pass (imf09.hostedemail.com: domain of rppt@kernel.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=rppt@kernel.org; dmarc=pass (policy=none) header.from=kernel.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1714286102; 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=/rehWXDbrDqU2i0HtTtHjlpE6sUQIdUPiwbyK7CIlaI=; b=EiHf2wouk9Hpi89sx7zhumV/CyR0g+ew97xicURFbif/cb6uBV6Zdp9qMrbxtBAhkjiD4R VFAJV4O4TZPJ+ata0SiuAeG2Mehfb+UCQTbsEHW5g6EyXEu/AxytXJXoZ7Vzu9UrN2z5Mh lt8ZTFrMg3G6/L4FmvxwTifxea6TCT4= ARC-Authentication-Results: i=1; imf09.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=NFnNagcm; spf=pass (imf09.hostedemail.com: domain of rppt@kernel.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=rppt@kernel.org; dmarc=pass (policy=none) header.from=kernel.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1714286102; a=rsa-sha256; cv=none; b=lULLwVfVfpZ0ltRbCjKSJabsCstTE+vHF2X249uSWcpOV3XbX+PlNFGqVw7/EhHbwhHymM 7Ul037RSfbnAuWvSmPKOAAMPm3qJbHBPv7iCdMRuo2GK+rhIZ3KRZuj2Eu9fS2/W7L/8j6 HOQaD2ySqNvwve7T+cBgK0+2UBXH76o= Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by dfw.source.kernel.org (Postfix) with ESMTP id 8C20D6065B; Sun, 28 Apr 2024 06:35:01 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 7F36BC113CC; Sun, 28 Apr 2024 06:34:58 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1714286101; bh=gGXNhBbfImPeZnJs87jnNoO7ISenhcnpz02YU249uJI=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=NFnNagcm6mwvKrWAK4nCHAx6kZP7OMn+eXbymaE2qzgfL4Eu8FRe2T3I2o5JdVegP SD+p0sqUzMfMlmdlyCUiRSvlu7sziirtS90CNFYqI9+290U7IwdUayxgDEtu20Je35 chLVzrmtTYJDuVqj7n1woEfj5ao7LxKO4Gv+qscR8QMxoNHRqfaXbQbA9gPM9nhNfd 758bwHgWD1/eAXRXc144oEDdiES61AhWwPyOjVIATkyyE+ykbmb6s5SlfLmUS4O4I5 joKnhpTwp9ZbJtaGD8z95Zn3hZoTpsnU3RlxEFrUmq0kxoTqSko/jbRL8uaElRsbXY 7DWpWP27KBt/g== Date: Sun, 28 Apr 2024 09:33:37 +0300 From: Mike Rapoport To: DaeRo Lee 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 Subject: Re: [PATCH v2] memblock: add no-map alloc functions Message-ID: References: <20240416120635.361838-1-skseofh@gmail.com> <20240416120635.361838-2-skseofh@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-Stat-Signature: f4dfsb8368fp6373nmn5339rjaw7i3p4 X-Rspam-User: X-Rspamd-Queue-Id: B3E6014001C X-Rspamd-Server: rspam05 X-HE-Tag: 1714286102-997748 X-HE-Meta: U2FsdGVkX1/I4XZIYaLm6yTDXbGEWsV8zHeJRDuSCp1AmFfeELttpZg0A24wVjs+YI/9ccLibBwv9DtLaZ7BgmYZ0CI5VHWXTAavBaH2jGC3Nr1Vgtrtl5ObRSqb/AmfkjMyyO0K+t1QP7xUx6H+FVw3dMdbDXi3iFIOkg7y7SdrBTavbP1UJ/GczW+S6L8u0Yc4iUPOwxvHZzeZ0qpzo9k6XOcvFRp5Dn6C1djEds0CK8CIDvnPt+dSBkuK975yL8ewPDoXDn3qB2k396AZtFpM8UzFOuzOa4HE1ap2D8LvgYKDyQoYfMgZ4EV2WduZ8jN9ujhOXNlWzdNnkNYDJxQShW3jyYw3dSbsLt6Xlx2vDQcVdjKECM68R4Qc3N3QbaT7ONx8qbBHbJF5k5IBe9/WK8WT4UQL27I1lYJBAzRhDKdAGmdEUNXT1XkdFOJHXwdavqdQxJNkFD0+WxuiQK3eHn3jaKJtr07yadYUCQ+hO0ZR3mVHPtIyvqfHno4oGvDsP7+2yk1+g3RWVHZ7w3Kj/EU2yXPeyJY4EyejoI1/sdbmDeTBHqJHQOBJjFBS4jZL9e7yY5Pn9+o7HA9EVLdiA5L65clyrKPvaIP43XZ4WmnbVdUKUp390ToWQCSjTWWw6GbvxwXM7P1G/r2ARiAkU1hwv5WbVtyBbrVfr9g6mEwqBQz3SjTuVM9/gGAFDKSsb9LVT3xZeZc9YHhHxoZVuVg3loqnY5my1bmv3KgDwEXasM6tPnLFbIH6HpkWA9ipG0VTg4Je4qar3QtOewGXs7TWAmS5y7Q9tKXnjN7ypdt6tIWMEufMKsFLFyPN6Of0n9Oc2Bs7RSMK1vv5PnWeDUNDin+wy066MwyMiQQcieu20T3mwpQSCtTJc9V2AyMUVI/8ki4Sai/+rwVsvjezmnwsMOjojI6dfxaJ6uFHdkLUtIpyVe4eRtAuT/ExJ+KuduIEx7IQev7jwaQ o+BwpNpb DkTPzxLiw76u91EpdNf7OYcpVg3ycBrCRk039AGHILW1zkTDNjx0W7ad6/HvfbGH/I7fKeM3UYuiy8mx4Xvtg/b37v3kGG0+FVuUPEnNOkNkNq6RqmNpYeJk9fXFyGaxjnIZIwFFSUW6fwpUHQatf1pK/nJ3zzbplSI1eWKCXSjg5O4QLpnf3EAOvT0dZ0fQvPAD8dkwMLEop6tn4Ks3xo0uJS8bh40vAjBIZMH87zWcsUV9/lBrxXotuVE+sxsYhL1iat0zGKhdZUhRAj7qxDSzb0LmWB7HYXnv3gZP+Ukke/sM= 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 Sat, Apr 27, 2024 at 07:24:23PM +0900, DaeRo Lee wrote: > 2024년 4월 27일 (토) 오후 5:50, Mike Rapoport 님이 작성: > > > > On Fri, Apr 19, 2024 at 10:59:52AM +0900, DaeRo Lee wrote: > > > 2024년 4월 19일 (금) 오전 10:46, DaeRo Lee 님이 작성: > > > > > > > > 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 region > > > > > > > > : 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 add > > > > it to memblock.reserved? We just need the region in memblock.memory to > > > > 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 sense > > to have a "reserved nomap" node in fdt recorded in both memblock.memory and > > 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 memblock > > 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. Read the comment about memblock_mark_nomap() > Regards,. > DaeRo Lee -- Sincerely yours, Mike.