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 2A72FC19F53 for ; Sat, 27 Apr 2024 03:27:30 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 9FBFC6B0082; Fri, 26 Apr 2024 23:27:29 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 9AC2D6B0083; Fri, 26 Apr 2024 23:27:29 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 874D16B0085; Fri, 26 Apr 2024 23:27:29 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0012.hostedemail.com [216.40.44.12]) by kanga.kvack.org (Postfix) with ESMTP id 6D2C96B0082 for ; Fri, 26 Apr 2024 23:27:29 -0400 (EDT) Received: from smtpin29.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id EB8DF12066E for ; Sat, 27 Apr 2024 03:27:28 +0000 (UTC) X-FDA: 82053876576.29.9B3C8BE Received: from mail-wr1-f50.google.com (mail-wr1-f50.google.com [209.85.221.50]) by imf19.hostedemail.com (Postfix) with ESMTP id 18F071A0010 for ; Sat, 27 Apr 2024 03:27:26 +0000 (UTC) Authentication-Results: imf19.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b="co59/2NA"; spf=pass (imf19.hostedemail.com: domain of skseofh@gmail.com designates 209.85.221.50 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=1714188447; 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=dpnMrCQGzjU8Ug2kmVhfBHxOZrHcuzQ7bFIBI4KiDEI=; b=tI2N4MIeQy9qvZks2cUsDiSDvOj0Qw4aSHdo2e7OG0lSJnm1mJzHrFTZOXt0XALeXoNcoX i+nFhlffHZZeyeeXN4onBUBSmVdjinTTe40MhpQ3AbQLw5iZ6s6Isz0PWHAJm3kj81akER Ae1ucz8kEgai2vGV9IG9jpYgpcpU8/A= ARC-Authentication-Results: i=1; imf19.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b="co59/2NA"; spf=pass (imf19.hostedemail.com: domain of skseofh@gmail.com designates 209.85.221.50 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=1714188447; a=rsa-sha256; cv=none; b=RYXl/zu/L/qpklkqhi7P0r+w8HLRBPPbxU3xhDeeUBKf2+vouHkCHKWe9TGGxvm5KV+NME rVe5eeE7jnUs3FFbeYDKYmPkjdQf0VU9YWRP9BLW26l3eWQ1evDw76LnjsDdqAorpwb4WK NBUUHjlzJSHf+QV4q4RTAIxZdWm1j1s= Received: by mail-wr1-f50.google.com with SMTP id ffacd0b85a97d-346b146199eso2149941f8f.0 for ; Fri, 26 Apr 2024 20:27:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1714188445; x=1714793245; 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=dpnMrCQGzjU8Ug2kmVhfBHxOZrHcuzQ7bFIBI4KiDEI=; b=co59/2NAb0p/gCVbtkE50yb0wHSRLjNESpEuwg85JH/vc4Wkl46lkJcGYHkLoeO2u2 8AxmBp9f0u1iQNJQe5Jcm8OACyFq66KAqKb4a9OeBXpN8wowxno58UzHwMbn2TPNoWkI umCXKL6QtnHoS4C8HB+Y7SZ47wy/5CcfYKnHdReoUg7Tzk3JBonjgeutCU/xCm8TrMyX oDuhb0epi3geXsQwsR5X4Y5s1XiIFTCsVvBBOYVn8pb182jTmTM3aVgoIOCipm0TjBa2 dtkmEOIvmzj0inbocGH+j7LtCZr+7hGMyA7jIH5pluePFyDHCAUAGrHyBwe/B4gEEPWo wyEg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1714188445; x=1714793245; 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=dpnMrCQGzjU8Ug2kmVhfBHxOZrHcuzQ7bFIBI4KiDEI=; b=DPx9vbWeRbdfAyijphXARjrrT6ShfpYUz8Kjma8MJs3Gv0j3O3ZC1+gOtB8OrYO2AG NJiXROid9JRb02GNlFG9g4hC4hFxjeFbXI4/Xx1ewoLLWo36lRchHQx+u9tZrKuOB9Q6 waKB/tjDFfcIrR1XN2U5rdRAl8s6V9zHkrzbMtm6yO09R0J6cX3D08dBfVZIkgwmkPTU s+t4UoWnB/L2eq5MaRXQoCko6SC/RTpVxO95Kbll11dOTlI+ZIbxJ0YrsfbbUPWKs5Gk emXUMH6rZ+gUJ/tDWHwJOD1H/bfMP3jn/Mh6Vs+mzFy2MxNTgLZs3d6y18lphFdJVyHI E5Fg== X-Forwarded-Encrypted: i=1; AJvYcCVCgyvPze/32DxwVz8vd7fFo8px8tXSgvtI29rX+jtszioHlcT0fg/FyWqAGn0HIipbIfCgFFm9dQ4UKLqVWmcrLGc= X-Gm-Message-State: AOJu0YxFDNmiy19ofknlxhqMM4OyxXGnripUd0hv4YF0mX079FsxYxJe 23zmHTCGXw88pbaS271BA4vTi/LaNnsi6bq35mUso6rd5PfiLOdbtP6qdCKK1MCrOwOR9K4KVLI nsaQga7k2OPxD4f1HU/eLpfaQ040= X-Google-Smtp-Source: AGHT+IEFe7QMo9VfHcy2+HTIPPLww0BG2I4FKP1Yh56fjOOjm8GoCj8GE8fMWioTFbFXpNKi96wWhX6Fvat5/cX0VxI= X-Received: by 2002:a05:6000:110e:b0:34c:7aa6:7121 with SMTP id z14-20020a056000110e00b0034c7aa67121mr1318366wrw.17.1714188445432; Fri, 26 Apr 2024 20:27:25 -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 12:27:13 +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="0000000000005e43d506170b9957" X-Rspamd-Queue-Id: 18F071A0010 X-Rspam-User: X-Rspamd-Server: rspam04 X-Stat-Signature: umrhh7dkhhhmiq36skkkd3nzj3f5jhd5 X-HE-Tag: 1714188446-592476 X-HE-Meta: U2FsdGVkX1+Rt5PAia8vBuwckZynBujl8VpmZtf9SIANjITSd7smdMaZgUqGU4wUGRYahl4HjmKngK/Ve8jpqOfs2GWUNUFmZ0jezmsy5XYS8+DObyd3s8RBnz11YOfIgKGTRpZG/39LQAi4F563Mqnbc2Ux6osVjm70nO/Y+fmBhNxLVDnpPxCPIHVsv3+UreKxLUgNhODUg83BhKOzaZDzzHP4dUtgovOd/b3bmf8VPFGeUXpVFcUIKY8bwJrZ5Wepi1qKgvv6ruF3bSQMWpcSmarJXqx8kwGK+J+9NJOR3lwZWvEQ1in5npbisTEcchL13+wvIqS4TqExw/JqrBwtCC/rsAwjDrMvJnRUYtctC3S05VJeOkcy6OKpRpXFvXtgi3hqfp07/SisaVXjzq1oruI9puAT+3iH7gdW705Em1vs/9cj2d+lsX2VyGERVlVHzpvQZznl2OK44d4cI3Ro/1v46e5UBI1zT+CU7ZhZtB/gSv3L1HSVVn7H57J620X6FYbNZCztk32SzhReb0AHVUE4NInoQcO+atBxFmcwn5nX8ab5YZSB0m25/i+rVBrccNZXs7ach5WiRNO8HPWGQQ4HDJJOmIYuMfuf3EI8krr/nZI8AZ/MZSBk7gut+RQjvvYJGBc4uIe6vB7YVwLzAgaKz3sfw6UvYvoTnuwuXv2iZdvnh7g7T2GPtj73CtHI7dO5XDsPgGKRPg5an7NmXqNNkp0rUpVVY6RchsCeHBZeR7e5vk6DqZm3QX/jDh9JuMSbiC2VkzaUIlHkDcK/S0ngSYgt+vnyCyvFOzpSGnFSpwtJ269x3FuwEJkhp3gLZkjKRBO0MQ6DXGX1KCz15op934E1vLzJcmycVroWRQWNh6ihkIYqqkc6xvYm8IJm0etPkduuWAxeAxkl66pnEi1BWjkTAtx9x0vb9NZsmxYXqZUT1S4SaYH0sJXKrWA5jdyvhu4jOg0FExB B/pJUndO O4v4Ml6l0/hasq8GTxSrbdBEx8w62YPNRj4bxuj2J4fDFBrusrNcG94B0jJORjTzgQSdKFll9H1LROetSQSvEqO5VRIinmtpVTIamUvhq5zdNZBIcfs10FxwsqqfFBM/QP10FvHInzjrQtqLC+BmrQDq7MRK+QAOzwM0qcLk7Kj/cFTQ2KeWirKuEFl/lQE5t6Q85teltLP624GvzZI1I+p6PQg7f82AG6GKCQ4jh8DQ1y9dHBysxogINvMB11pHETJrnzCoxOW4EalyFz8+qt198kBiFjTX2J6HUWMy9+H4MUQdwalUm/BcgQx8gwuXvNA5gyd7ZVTwCMVuIkFqD2dUUtia1qRxIEp3DVCglynDuT8N6MVtPXccRvMTxaUCthAc/QIOoIyfW6y/0PmD90ESRxTuDFnfEvkyoIKiwPsGafCNAQZ3NC6B4Dla9Ch0raAIkZ9c4mlZdomkLY+4UIvJvd0bpEDop3/+O4GSJOyYiNa+HURRd06YkATNzoqmAzxKvVKyHpKprx2hMrGVmdi79FODaBAGeTS7hd4t3q0PyeNpVqd8sera+xSI1LoN1L8lqn3RA0vWr/x8WKpar1OM2q/nm7S1CKWFR06fU2xjmlrxgmdhpCfMt0wF+9YZTtXHt 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: --0000000000005e43d506170b9957 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 2024=EB=85=84 4=EC=9B=94 27=EC=9D=BC (=ED=86=A0) =EC=98=A4=EC=A0=84 11:42, = 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: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:4= 6, 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:= 04, 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 shoul= d >> 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 >> freed 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-m= ap >> > > > 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 >> 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 >> > >> > 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 > Sorry for wrong email format. I just re-send this for kernel mailing loop. > --0000000000005e43d506170b9957 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


2024=EB=85=84 4=EC=9B=94 27=EC=9D=BC (=ED=86=A0) =EC= =98=A4=EC=A0=84 11:42, 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 1= 9=EC=9D=BC (=EA=B8=88) =EC=98=A4=EC=A0=84 10:59, 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 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, sks= eofh@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

Sorry for wrong email format.
I just re-send this for kernel mailing loop.
--0000000000005e43d506170b9957--