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 93193C4345F for ; Sat, 27 Apr 2024 02:42:43 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id C277F6B0083; Fri, 26 Apr 2024 22:42:42 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id BD6636B0085; Fri, 26 Apr 2024 22:42:42 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id A9ED06B0087; Fri, 26 Apr 2024 22:42:42 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0014.hostedemail.com [216.40.44.14]) by kanga.kvack.org (Postfix) with ESMTP id 8C0116B0083 for ; Fri, 26 Apr 2024 22:42:42 -0400 (EDT) Received: from smtpin24.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id E52E6120615 for ; Sat, 27 Apr 2024 02:42:41 +0000 (UTC) X-FDA: 82053763722.24.D3E735C Received: from mail-wr1-f46.google.com (mail-wr1-f46.google.com [209.85.221.46]) by imf21.hostedemail.com (Postfix) with ESMTP id 1FAAF1C0005 for ; Sat, 27 Apr 2024 02:42:39 +0000 (UTC) Authentication-Results: imf21.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=ZMRljxGN; spf=pass (imf21.hostedemail.com: domain of skseofh@gmail.com designates 209.85.221.46 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=1714185760; 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: in-reply-to:in-reply-to:references:references:dkim-signature; bh=Qq00vQa695O/0k/UtvaKZYNeRq4NN69s/+Nl1kDYiVU=; b=5N8VLdPfOR71cVF8rX33b6HnA/dlFfVmchlpIu4k/yRfoRZoFnBRE0sBZQzN5J+/rNrmsx IamR9tzqxrcXE0guCaXpeI8aJS2rkmfKU6R0D1+9TKnIz7cIr0bS+nSeF/EtBbP1ER8E5S 5wkbWP6OhBgX685Q3xdQsG2UvbQmYUw= ARC-Authentication-Results: i=1; imf21.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=ZMRljxGN; spf=pass (imf21.hostedemail.com: domain of skseofh@gmail.com designates 209.85.221.46 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=1714185760; a=rsa-sha256; cv=none; b=GQernnAlx2Q0IdY5KoALYSGXVL3saWosDuEp9lURIYpWJk77ewPlRPyXQ+SP1zNtYNFpM2 Z1KeYiGvlfqZrHxKjd5ea3sX+Yuic6zRR7ZZZEgPyKFa3b2DMnY/miNOaXwzcO+ZMr9RcH 4ie8MYfQRfJGF/jEZ/J0LYDyM518XNg= Received: by mail-wr1-f46.google.com with SMTP id ffacd0b85a97d-346406a5fb9so2147871f8f.1 for ; Fri, 26 Apr 2024 19:42:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1714185758; x=1714790558; darn=kvack.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=Qq00vQa695O/0k/UtvaKZYNeRq4NN69s/+Nl1kDYiVU=; b=ZMRljxGNsGhdHs66B/xOht93Fm9Ke1nC2ZVGZzDI5Sn8BNX+Fc5Uwl0O3Rx+NkjVZs v4hEx9Bmrf1gv3PaAtlYPSLZ/JYahps7XLl3u0W0EgkqbeRCCOSUdsIQyFYM2gMj3QcQ fVQmfaGhMYMRnL45PAxL1ZhWWut/WNhR4x1jY7UnCDXH0eTWxbxqB8W3o6/AD+CLUWnw hjHKyhUeLJOZPlsLK8m2t2yteyXqc1SalUTQb7jHn+KHwGRRu63scsUIl2+vuW6C2XzU Tih0cqy9AquimKJzA0L5176MNd8Ywa0OB6z7PDqZej9gDWBBpMLUoH2Q6hTbJG+BluDT 3ucw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1714185758; x=1714790558; h=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=Qq00vQa695O/0k/UtvaKZYNeRq4NN69s/+Nl1kDYiVU=; b=cGWhu1Fr1NQALu6oqPA4x7zd+e/BWZHNjzsq3SrvpwYOxUZfTolHssZqYLVZALZPMy CslohBUqw0a0FeL+d9FrvCfiWV37RpIkQnCSPAFAtT6er99aHFfCYkVuwaBxCTdcyC/i Q2eoUNTGfxbmGVbyVDyVnSBmgMJBeKdcdhvu3VvMv9JtV2//fGT7cgvOq5EMVjXNyahi K7me4WjsJvqnX4TkaeODg2VuWm6Keyan/VyFNq0Pu6OlZrIYkGctWPq5tagjAwqthsVe teznQZVqmwqn1dHM4L3VCl7unlhRmXZrJOqq9wpjb43LUt4zr7dsIm1islIXjPEEnVFY RMlw== X-Forwarded-Encrypted: i=1; AJvYcCUA+mHjwq3NSgV/GS7zj3PJCc3bUh7rQjlshuuINS1A1RM9xuX/WqlTExhYmjGkg7VnAQMY+ljU/wWrIPe8Z+Nr310= X-Gm-Message-State: AOJu0YxuxLYz9/pnam27agaMdmDAjGfjqTp7epJnw88Uygb3/53iOq1h DSXlYtC41GhEIEmEjjJhMihGtMCHUeQulVsaLAgDqiErE+EBe0A9KZab4DxLK1aQP7db99mAICW kjRDVoqRPkLPNbHBaJktBJ1rhIT4= X-Google-Smtp-Source: AGHT+IFtx4Q7Y59iNqkFm/+yx7a0ST/IsyFuo+Mv6I5Op4H6JWSMZz0/PWRcBYibhgFYala8z+QD0aOahGJoBUggxIs= X-Received: by 2002:a05:600c:34cf:b0:419:f088:249c with SMTP id d15-20020a05600c34cf00b00419f088249cmr3676523wmq.12.1714185758180; Fri, 26 Apr 2024 19:42:38 -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 11:42:26 +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 , richard.weiyang@gmail.com Content-Type: multipart/alternative; boundary="000000000000320d9306170af996" X-Stat-Signature: xa9buziabprbr5p1tjcihw84yy8jb6fi X-Rspamd-Queue-Id: 1FAAF1C0005 X-Rspamd-Server: rspam10 X-Rspam-User: X-HE-Tag: 1714185759-789798 X-HE-Meta: U2FsdGVkX18VNzRXrsTz9km+5ilutzKeo6snjOwbPZfpW9cOrZbw3m2CluWmgRdATcvvaToG87vipSDxAqCWHGUOBOkYRpXL+dmLlisNyW7YnsqSsh0IeGoBPlo0XMdfrUrEaWncaHGiDWHMT5BplMTR/0VECYoJxfIP8fSkj4Lhw5YzTYAiOpT3JQ29NwFmtVn5DjywMnCHiSu8CC0Gh0MbPxal2tnzQZ0620bE2NutbpChmxSHXDtRDfYOULMobN5qaNvYRvKlebW9sNPTLU3lVgrkh4CwN4vnzGuwnt0jxqIap4crgLxRNxbucAyU5JtmqhtMEB6TgNo9XgrfsXK6SY9PB66WNiw+3FShkpHXo4FJd2zMJ3lcslvDe6RKGcWIjPiIextD027tBlUpPg7TYFAJc70awMXq5Z/yvxt7c6GOysKu3pytudaPhlzUy+WJMFvlUDR0VMWcNxz67sQZASibavuG+gH8gLeDuZD1RNQ4ygFmKA37vAnD7UzifRgxbSANGX1w9+u0kGjRKlVOKH4EzZ3s4vRbcMpFDRrjYu+GcmwEfxVKLo/vSN0uRsvldeLQVWKXwjpUsz/Ptlpw7BIjuMT86YsZAWFztEi9Ubl26s6Fk9bjHi99iYtF4fGgPHTr3Q0MA3qpFttgyfdHZjPR2RFRow0P5rkCVntpYX29/5nPv89ut1V+aL6Mt0yHShqriFBEdHjMA7S+RU0CzbIoc2LfpGAyvMX3yzcEiL+atp5jXkPr5I2knLNFy0OYDy1swY5sy5xD1gVQexFp4QRrlZmwmmGEY7qy0wziw8hKwaWszZU5iLpseILbKm++0d/jak5HfKJOLdrrtkdQE2E76LK7M5l+MaJBrhQCITuhK4FyTZRxzXJrW9hto5tkLHUGkzhl2WCU+xc2Pc9DX59ee+E1DJsZaMxZDJJ+Rmx9MTwMQC1AtsmVQMkN8duKoVyu+KD5DbeABVX YpOM2lAm vYqOuZonL6R5ax4gt8FJ19LJkUP/WpEyO8QsfJcp26x/kVQdHmoqBw83sYzWvZ3NVHRcbyhS7O3PMCMENRHWyMFtGHCVBltbxvO+xQUogCVuB2aTuvJs6B3KojKEWLbVrfunp/JrMDmgfu2vG686XRAdiqhBpFrtJNW0fm+iaXmCfCZEf83p9jLewocKArTi4gpueJCqVPo4nOuN/2SZO4c/cx0k8ojJEyJAwPWl/KNdG/wd63XBnKy8DIlUBBkl1NCWNADoCiMci8zjyaUXLlIiV3CfO0KOlevPJxUSF35Erv7su/HO4DfU6yA1e61fkOl3YsTuMYGI4tJASDl3H3DzRpOqbJ4sCWwlWZVe/dTZLH5+EDXmA6sEJMrzbGrs4EbC993JPfy3y92W01U4tL83sCKpaDst28UjiGtaAi73cTkYWQ49U57cpUl/qsZujvCuMEoI1qxJi5hzr54fCKbc1O+hJDJ2nxGfzmHvFYFcCwVwT1j4kUU6MAAqoKgc+2EaMLpW/IP27cEcPnZgR/FF0Iir7eMdI/It8uqzKsbZRdi/AfhihBTpeRPrF6rUo+xRF/LAcc21VDxM32pibKIF5U8gYrUjOonfIyiX3lFlHPybYFPyhJhruEinJbqVgKF5e X-Bogosity: Ham, tests=bogofilter, spamicity=0.000072, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: --000000000000320d9306170af996 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 2024=EB=85=84 4=EC=9B=94 19=EC=9D=BC (=EA=B8=88) =EC=98=A4=EC=A0=84 10:59, = DaeRo Lee =EB=8B=98=EC=9D=B4 =EC=9E=91=EC=84=B1: > 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: > > > > 2024=EB=85=84 4=EC=9B=94 19=EC=9D=BC (=EA=B8=88) =EC=98=A4=EC=A0=84 3:0= 4, Mike Rapoport =EB=8B=98=EC=9D=B4 =EC=9E=91=EC=84=B1: > > > > > > On Thu, Apr 18, 2024 at 11:54:15PM +0900, DaeRo Lee wrote: > > > > 2024=EB=85=84 4=EC=9B=94 17=EC=9D=BC (=EC=88=98) =EC=98=A4=ED=9B=84= 3:03, Mike Rapoport =EB=8B=98=EC=9D=B4 =EC=9E=91=EC=84=B1= : > > > > > > > > > > On Tue, Apr 16, 2024 at 09:06:35PM +0900, skseofh@gmail.com wrote= : > > > > > > From: Daero Lee > > > > > > > > > > > > Like reserved-memory with the 'no-map' property and only 'size' > property > > > > > > (w/o 'reg' property), there are memory regions need to be > allocated in > > > > > > memblock.memory marked with the MEMBLOCK_NOMAP flag, but should > not be > > > > > > allocated in memblock.reserved. > > > > > > > > > > This still does not explain why you need such regions. > > > > > > > > > > As Wei Yang explained, memblock does not allocate memory from > > > > > memblock.reserved. The memblock.reserved array represents memory > that is in > > > > > use by firmware or by early kernel allocations and cannot be free= d > to page > > > > > allocator. > > > > Thank you for your comments. I used the wrong word. > > > > When I use 'allocate', I mean that the region 'adds' to the > memblock.reserved. > > > > > > > > > > > > > > If you have a region that's _NOMAP in memblock.memory and is > absent in > > > > > memblock.reserved it will not be mapped by the kernel page tables= , > but it > > > > > will be considered as free memory by the core mm. > > > > > > > > > > Is this really what you want? > > > > If my understanding is right, before freeing (memory && !reserved) > > > > area, we marked the memblock.reserved regions and memblock.memory > > > > regions with no-map flag. And when we free (memory && !reserved) > area, > > > > we skip the memblock.memory regions with no-map(see > > > > should_skip_region). So, I think that the memory regions with no-ma= p > > > > flag will not be considered as free memory. > > > > > > You are right here. > > > > > > But I still don't understand *why* do you want to change the way > > > early_init_dt_alloc_reserved_memory_arch() works. > > > > 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 regi= on > > > > : 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 > > > > Regards, > > DaeRo Lee > Hello Can I get your opinions about this? It will be very helpful to improve my understanding of memblock and reserved region. Thank you > --000000000000320d9306170af996 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


2024=EB=85=84 4=EC=9B=94 19=EC=9D=BC (=EA=B8=88) =EC= =98=A4=EC=A0=84 10:59, DaeRo Lee <s= kseofh@gmail.com>=EB=8B=98=EC=9D=B4 =EC=9E=91=EC=84=B1:
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 <skseofh@gmail.com>=EB=8B=98= =EC=9D=B4 =EC=9E=91=EC=84=B1:
>
> 2024=EB=85=84 4=EC=9B=94 19=EC=9D=BC (=EA=B8=88) =EC=98=A4=EC=A0=84 3:= 04, Mike Rapoport <rppt@kernel.org>=EB=8B=98=EC=9D=B4 =EC=9E=91=EC= =84=B1:
> >
> > On Thu, Apr 18, 2024 at 11:54:15PM +0900, DaeRo Lee wrote:
> > > 2024=EB=85=84 4=EC=9B=94 17=EC=9D=BC (=EC=88=98) =EC=98=A4= =ED=9B=84 3:03, Mike Rapoport <rppt@kernel.org>=EB=8B=98=EC=9D=B4 = =EC=9E=91=EC=84=B1:
> > > >
> > > > On Tue, Apr 16, 2024 at 09:06:35PM +0900, skseofh@gmail.= com wrote:
> > > > > From: Daero Lee <daero_le.lee@samsung.com= >
> > > > >
> > > > > Like reserved-memory with the 'no-map' pro= perty and only 'size' property
> > > > > (w/o 'reg' property), there are memory reg= ions need to be allocated in
> > > > > memblock.memory marked with the MEMBLOCK_NOMAP fla= g, but should not be
> > > > > allocated in memblock.reserved.
> > > >
> > > > This still does not explain why you need such regions.<= br> > > > >
> > > > As Wei Yang explained, memblock does not allocate memor= y from
> > > > memblock.reserved. The memblock.reserved array represen= ts memory that is in
> > > > use by firmware or by early kernel allocations and cann= ot be freed to page
> > > > allocator.
> > > Thank you for your comments. I used the wrong word.
> > > When I use 'allocate', I mean that the region 'a= dds' to the memblock.reserved.
> > >
> > > >
> > > > If you have a region that's _NOMAP in memblock.memo= ry and is absent in
> > > > memblock.reserved it will not be mapped by the kernel p= age tables, but it
> > > > will be considered as free memory by the core mm.
> > > >
> > > > Is this really what you want?
> > > If my understanding is right, before freeing (memory &&a= mp; !reserved)
> > > area, we marked the memblock.reserved regions and memblock.m= emory
> > > regions with no-map flag. And when we free (memory &&= ; !reserved) area,
> > > we skip the memblock.memory regions with no-map(see
> > > should_skip_region). So, I think that the memory regions wit= h no-map
> > > flag will not be considered as free memory.
> >
> > You are right here.
> >
> > But I still don't understand *why* do you want to change the = way
> > early_init_dt_alloc_reserved_memory_arch() works.
>
> 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 rig= ht.

> -> 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 th= e
> 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 tru= e, we
> mark the memblock.memory region as _NOMAP. And if the return value
> 'err' is not zero(which is '-ENOMEM' from memblock_iso= late_range), we
> free the region.
> - 'nomap' is true -> memblock_mark_nomap : success -> no= t 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<= br> >
> Regards,
> DaeRo Lee

Hello
Can I get your opinions about th= is?
It will be very helpful to improve my understand= ing of memblock and reserved region.

Thank you
--000000000000320d9306170af996--