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 000B0C4345F for ; Thu, 18 Apr 2024 14:54:31 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 836D06B007B; Thu, 18 Apr 2024 10:54:31 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 7E54C6B0088; Thu, 18 Apr 2024 10:54:31 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 6ADC36B0089; Thu, 18 Apr 2024 10:54:31 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id 4CD4A6B007B for ; Thu, 18 Apr 2024 10:54:31 -0400 (EDT) Received: from smtpin17.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id F21D5C0C6F for ; Thu, 18 Apr 2024 14:54:30 +0000 (UTC) X-FDA: 82022948700.17.C45CF6F Received: from mail-wr1-f44.google.com (mail-wr1-f44.google.com [209.85.221.44]) by imf16.hostedemail.com (Postfix) with ESMTP id 27D86180006 for ; Thu, 18 Apr 2024 14:54:28 +0000 (UTC) Authentication-Results: imf16.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b="aLINhD/y"; spf=pass (imf16.hostedemail.com: domain of skseofh@gmail.com designates 209.85.221.44 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=1713452069; 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=OvGBkvFoWVsZGonrRvzCmb0bTHJXTs/4/G/PWLo4Ruw=; b=CpkyOma+pO6uDAMib2C3gOKIxJWL8IuGzxpMm+zYfb2a9JcufjVWPZhdZo11CmdLyD72RD H/1weYV8aOUV7vtGrl1/g5aQAzkDvpo4Z6/myzxSZh4AlcHEQnq1JxVuhn6vgmmIa5bkit xkIaMKx4qTi/7/k5RM5d5aKSrDe3jik= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1713452069; a=rsa-sha256; cv=none; b=1N/dwinGKRA27A1O+Me4srbpVFhFBTdbd+05tOWJqQ3MGIce1R2UcthNTL1FP2A6+7X5bB hwziMrfpXvFn/udL4q6o999M2mBxkNCZ4MbRejglRZEooMRnJG3edfSSlZnA40l8OQDrcs Ky8gcxYRgD/J9U8mZEYPIX4Psnbyyo8= ARC-Authentication-Results: i=1; imf16.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b="aLINhD/y"; spf=pass (imf16.hostedemail.com: domain of skseofh@gmail.com designates 209.85.221.44 as permitted sender) smtp.mailfrom=skseofh@gmail.com; dmarc=pass (policy=none) header.from=gmail.com Received: by mail-wr1-f44.google.com with SMTP id ffacd0b85a97d-3465921600dso814542f8f.3 for ; Thu, 18 Apr 2024 07:54:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1713452067; x=1714056867; 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=OvGBkvFoWVsZGonrRvzCmb0bTHJXTs/4/G/PWLo4Ruw=; b=aLINhD/yUlS0iZ9KE+rzCnLcMzWh/Yy9slMZssafMqp914ckvfxVS1sa/OzNuVDiFK Nbi/AJzre7BGmUXJ0kQPd/zPp1UsLf1SatPX5C+wosjH9vVX85ZfGdeYhYFSHjM69g6r qKIaXw4/mpJ5UH5RBBbmY3iLxTR+FY3pICWIH4R0rsjBXfdbBzRS8flR1bdiekQApnIL 9UFtuzxCiUebH2bgzmGGv9SXObdhmWgLfrH372cTNtOrAXw/mywww0AXayIJ35oQrUwL dbyt6dn+/GOeW0gcxEBNz6mMK6GEJ6VJ+FHZkvut0wNWi0zObCdz9Q+CvnIk0qAvEQo/ kt9g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1713452067; x=1714056867; 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=OvGBkvFoWVsZGonrRvzCmb0bTHJXTs/4/G/PWLo4Ruw=; b=JmNhC/GBm4UYsisgZD5zvHdefC7tnO5CgQZO775dHGWL+INPQ1Azwz+FteWs/47DJu CThv4KRxwM3JbeRf5A3v6bY19Y5QFAAiw0Ovs0AsOlZ75se/0/hulPptuWnWIfzPC/1M EXjmmcKOOAbfUcHQG6sqhj7nK57ulGydNgei0wwSuKSYTr5UXi6N7QBEvy5VSC5tXHB5 hF4vIpaffHYuL4B06DqZ3PfSB7kqv8e+XjMs/ybeBu9yUZqWnQ/zRDcyujLqUbR+vKpz nF5jbe6iyexHfOpV+MMHD8DJOwYqYmOvFQzUyWOu3nx5/kca5OeZ3aNkv+NV6j6s57WS RkxA== X-Forwarded-Encrypted: i=1; AJvYcCXjq6yqd3KluFR6ywxpNMg5AlEjk3qVYsm4uHPDBDPWhUDXLI2pckZjhatlsNKFbPjQHAMZF4adiZIeKv014TyqxoQ= X-Gm-Message-State: AOJu0YzTotXJ8eRp5Scx56J290QNYI8AWirANkbczGb2pceH7wmRo3Tm RoHMCkTovR+OuhJgmjMhmKmjPml69Rx05GvUnPYRpwJM3kUCcey1ZEKpJmsT+vRJlXnIQx03uHf 4tCfNqE+4VXt9PUP/rSED4fthieA= X-Google-Smtp-Source: AGHT+IF1GOB+9k0yqpKSFsOcg6dnXs0PLwnWjCVD16905JB4IckCABWiGjTamMXxYATZwLvowgjCD80p4Zu9jj0+CjI= X-Received: by 2002:a05:6000:1:b0:346:d2c0:7682 with SMTP id h1-20020a056000000100b00346d2c07682mr1734554wrx.30.1713452067341; Thu, 18 Apr 2024 07:54:27 -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: Thu, 18 Apr 2024 23:54:15 +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: h6e4jaue1x5oxdnxhpye9a36sj795xnc X-Rspamd-Queue-Id: 27D86180006 X-Rspamd-Server: rspam06 X-Rspam-User: X-HE-Tag: 1713452068-696505 X-HE-Meta: U2FsdGVkX1+SWQvZuqtO8SE4qcrMzLCgKzwT6eGAYl4+8ihxSwVovlLZYuUvn3kPCwW8947BSQf8FOQmM6zwGzOdj9eocSqHQOks/2YKiQnwTS5VLBClM5Qit0XjyRjOOKQtqBt5MdhjWwu5dLmTmy6J0EhQrAAPnjRRj8wfUsjue0raHFCy4hM8DFSL151VN5EvViA03YKio7aRj4gKUYOqefhTI6Mlkz79Unvd9MpIN3NerccmUeNO7LwsdjCzNNF15U4pWT2uSPkrgU1i1da8EKx32S9Njf+msZlfG5fsnm5A/x9MmiLKfw/zoDJWGBCShpLP0ThuBtiuQLhVo9vSaFcwLthWJLG1kWtIwDTkDkX1vMxFQS8xLoMhMTBQQzvquQhur3W7CIYSbKwipscsr4taV907M1kUuMLoZHCN+neAyKfjU6gjUSIZK1Wf/3jhob3wpv76ajmHckxAWfbFAlTs9WQV21Mwjco9C147crRRUZlrlxeJ7uAnGtNmcyULWuEHRmvWHrl9kmERJqIl6hDpCJwTIxNtLMqhVpurV0yFOvRhBVIJ+LTHEsd/oCCHt+U8k2aFhliVSNTR1Hcm9ECArrdwUVUknbXAypmlTO1F0Y+qZJG8r+c+mccGzAtZKeSOI/vONLshyCagRoWrQpPJydKb2u3iElM4GRnd4q6ArlBzQUfZS2M3iIzcmkAzMzjFQSd6i9X8n9QAGkrQdf0V+FNDZPwf086r3iZjPdtH7Q77cCFfoOOta9BjCP9/SqAHXsdqXOjD3bLlZyCELtAbVJtdthddJTVvpOnZnAVjNV1izKL851dTCRVX3HWE5oF2TSpERIv192H2GGujrE86++01pEbwwM8N0yz9t4EbuC013Curv4WuVNfjIs3bKeY/7QsjtlvZzZXSa7L9UAzBYfilULo3h0MIo08ct8NUNDvd6OgG8b0OT2uLc5TtUed4MrLtLYEbvDj lUeaLOaN 9tdv44fKom2XEBE58YhYggB8bnnkWtBqK6xSJ4avSiO+bZ7YOjWNsA6PczLq1wiC2xmBziANsQaIw2noizrZeR7t50+ZXyWPHkuNreREkSQoNhwTzGG/MD1OlwRNEFEgGuJkAz2dT/l+RC0EGRmtTgCz90/+O6qs9pe5UNi4BzcrFwWzhrEHd47wjD7whEo+DEz9c/gGgiTRL86R8AUn4cPk1GFjJnVINYy4IP0HJ1G7++g5/3iO4+dFtxtSQHAykmH/26PNkuNRjARkGLIeeJAWJIz9xVB0BM7oWqGfsR0G+aZmgcFgvEH3X/EJQWJinfO91qPnx0Ephyj5wA2H3lKLGxxDcYxefF2q1VGROZbwxBScxU9+pTxS2aeyw3hHNuzeH3Nfn6ivOMVoNXTt/jewU3uxuCaVL8wc9pZPFeNMv7hC/H/FCPGodhh0F4mekUZkiA1yzPTu9rHo= X-Bogosity: Ham, tests=bogofilter, spamicity=0.000005, 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 17=EC=9D=BC (=EC=88=98) =EC=98=A4=ED=9B=84 3:03, M= ike 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' propert= y > > (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 freed to pag= e > allocator. Thank you for your comments. I used the wrong word. When I use 'allocate', I mean that the region 'adds' to the memblock.reserv= ed. > > 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-map flag will not be considered as free memory. If there is anything I think is wrong, feel free to correct me. Regards, DaeRo Lee