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 86700C48BC4 for ; Wed, 14 Feb 2024 08:11:55 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 0E0AE8D0011; Wed, 14 Feb 2024 03:11:55 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 092FB8D0001; Wed, 14 Feb 2024 03:11:55 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id E73DF8D0011; Wed, 14 Feb 2024 03:11:54 -0500 (EST) 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 D32788D0001 for ; Wed, 14 Feb 2024 03:11:54 -0500 (EST) Received: from smtpin16.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id A5C3CA1E71 for ; Wed, 14 Feb 2024 08:11:54 +0000 (UTC) X-FDA: 81789690948.16.D98D1DC Received: from mail-yb1-f174.google.com (mail-yb1-f174.google.com [209.85.219.174]) by imf02.hostedemail.com (Postfix) with ESMTP id DD5828000B for ; Wed, 14 Feb 2024 08:11:52 +0000 (UTC) Authentication-Results: imf02.hostedemail.com; dkim=pass header.d=linaro.org header.s=google header.b=TzhqDRjS; dmarc=pass (policy=none) header.from=linaro.org; spf=pass (imf02.hostedemail.com: domain of dmitry.baryshkov@linaro.org designates 209.85.219.174 as permitted sender) smtp.mailfrom=dmitry.baryshkov@linaro.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1707898313; 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=KfOoEa6KDVG5lBUOB2ugHyccJS6WfRjSfp0n81i8FVY=; b=o3JJzE+XKsLm0IXzGC0Japy6YTDwlgFaD+AmSC3GxUl/8afb4RwFllwm7vblyHOW/rI77H Jbkqy8333N9aFxDLZ+KjsBNo/bi2EVPGsR+C3rNMTOgh8PELRUo5d7+NUIeASydnjJxzwZ Rsfs0KuXnEI8xkvk7kQi5p/qHAWBCzw= ARC-Authentication-Results: i=1; imf02.hostedemail.com; dkim=pass header.d=linaro.org header.s=google header.b=TzhqDRjS; dmarc=pass (policy=none) header.from=linaro.org; spf=pass (imf02.hostedemail.com: domain of dmitry.baryshkov@linaro.org designates 209.85.219.174 as permitted sender) smtp.mailfrom=dmitry.baryshkov@linaro.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1707898313; a=rsa-sha256; cv=none; b=xlN50Cnzj085frJ8KLbyaAlQaTUi8RchbFYvcdeByGX2IPIokA5Y21kspcKFLDm/Nzr1bW +WDoyKzdMLQSRQWVJZH135yxpGr+unSHKPJAf6x5j2RZweiocrLJ6TrpE7TBRkqSDpBGNH oAKUkzv+weIWepP0k5gPqSjECQ+q+z0= Received: by mail-yb1-f174.google.com with SMTP id 3f1490d57ef6-dbed179f0faso372310276.1 for ; Wed, 14 Feb 2024 00:11:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; t=1707898312; x=1708503112; 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=KfOoEa6KDVG5lBUOB2ugHyccJS6WfRjSfp0n81i8FVY=; b=TzhqDRjS+4Ip8wksoRRKJUIukLZz9nkDLAKH/h6bvRJ+PWJkKNnqdCZZ0kToAFjdn7 v1gi0NCofwzhr3GR8NYpLqrQF//ELE+Nu2jn5aSUFFWHPccuVlpAgpSoXSqsbU+yHWl9 CTf4sH57H+hJCcHZMA4wQpOWWob+CjeZoZkkP6hCA2uCXdbVbtRcMaGqrU9wej4qhSJu 1qSOVJL02X24nahFWGC0TvTjSy004ETFIVF2b/miHZAtJNDsjIapETVWb9Ktu4WySwBj 8Of6h/T0v84DTbOqPiwZbiAkHZAYRj+nZqDIbPNGZmdoZic26eT5k5YI5mlL0RyltzT0 HuNw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1707898312; x=1708503112; 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=KfOoEa6KDVG5lBUOB2ugHyccJS6WfRjSfp0n81i8FVY=; b=XNENlC4ARC6i9BjCgKfmfaXopzwZBUB8XYE2VQxMXqTHMRi4ClqyixboQ03JuJeJyO F5bLygAu18jNt5O2qjKHecfENrud3tx3bEHAkGOXDD0TSCkBFaRzJIFvz21ObemVFHsk fVSI+WeMPlMyjnFzkKtewwJ3dBzueXHT/3PeoHAp3YIGpnT1fBhlVrl1LfEHH/yPque9 fw1lUQyf6Ey+/IciDzhx2r43qsrkdvlpic0SC5ZMoBSpbzLVxAMmDSRGhCHa63mR2ZsY zGn5smiuusaHG2RuQ6noHq5K9hd5OwccV94ns6xpuwKj86RCLADsgbBfY3euPf9dZGv3 m1Rw== X-Forwarded-Encrypted: i=1; AJvYcCXeZ+f45E5gnhvp+9RxrcYliWlGJ0FHeA3f6Wok9zN8PLpCcRL1fa8RUzQjR1R1wkhWRll6iUaLSopYyi2tZDeNgxM= X-Gm-Message-State: AOJu0Ywde59htM2LKFeOmFUSoPD6g236BsLcuOAGZSLcloyF48bKjFGa eTydMSEhjnsMJ4XQAfo8LaWqlbaRY/+B8BCmKXnAa8l5peHy6SV3Dm+ZCXSqAS6f3V409eAPDF/ HroZ8F+EFRgv0bBXHQp08ZzVHWXmrpaOI/5Wf7w== X-Google-Smtp-Source: AGHT+IFAn6NP7cUBJnGhZzmKFmr3z8S4XNhtXr3hHrBsJyxvM947Lhuu6U6liOw/rKr+h9SZcVchZb+pkdi1vk3t71U= X-Received: by 2002:a25:3c87:0:b0:dcb:b072:82d8 with SMTP id j129-20020a253c87000000b00dcbb07282d8mr826745yba.15.1707898311745; Wed, 14 Feb 2024 00:11:51 -0800 (PST) MIME-Version: 1.0 References: <1649704172-13181-1-git-send-email-quic_faiyazm@quicinc.com> <7b18bea8-b996-601d-f490-cb8aadfffa1b@quicinc.com> <42f28e7b-c001-7d01-1eb6-fe963491898e@quicinc.com> <22aca197-8d18-2c9e-b3c4-f6fdc893ceb1@quicinc.com> <76cb3b37-5887-404f-95b7-10a22a7ba65b@quicinc.com> In-Reply-To: From: Dmitry Baryshkov Date: Wed, 14 Feb 2024 10:11:40 +0200 Message-ID: Subject: Re: [PATCH] mm: memblock: avoid to create memmap for memblock nomap regions To: Mike Rapoport Cc: "Aiqun Yu (Maria)" , Vijayanand Jitta , Faiyaz Mohammed , karahmed@amazon.de, qperret@google.com, robh@kernel.org, akpm@linux-foundation.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org, robh+dt@kernel.org, frowand.list@gmail.com, devicetree@vger.kernel.org Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: DD5828000B X-Rspam-User: X-Rspamd-Server: rspam02 X-Stat-Signature: ixs5mrarwgc75gs9cfocwkoxsuuantzm X-HE-Tag: 1707898312-844590 X-HE-Meta: U2FsdGVkX19m0BiJ92ysE+FqsGM+CL3BQAKoVF0ZAVH7Y5Kc4+L0BCbnnZeux9TOnoLY3aI9A4lshWcnz4pGkuL+WG/kRMvwEpSQVUynuMV0hJqK3cIkwfWJqHCWj++a56rXmYJYhr6SAEA6K9GDjUOoVL3LBZ0byX8c9uvUcrXHhCfxK/PPBAVf2vRCQh/8N/3MwxZUJ/fQwFv9iNqiehcXP9LcZpFasMk8zgwx1z68g50QtHyYIXoYpN+L5udDPQoTEt1t3U4lxm6xIqLFBY1E9uh0heVcd9p6ClGHpI7K/Hfaowl+lqZgRjPHWhlh2WRbbytj0b66SyPr49v/kfNC2H9QkdeD4MLo6fE9MEzeSHsAIyt+yBrszvYZUYjNhyleSzUUmaKo5CD3K4Tzi6mYJZe85ELdExWvtmrxGmCaNIsba3lT0ii832mMiCARRfEbSQCkHQ6f0jLdJC1A0mjOt2c9+DsdCqFOUnVuup7swhT5O4sZ9vp43vArsAg7+tFCdVXX14zcwsh/i78Alowd0doHOsxLC/64XzhLhQNfziaWVtkT+GVdptO3Kcui3ZGgSGNCgXtPb/tzti97RZewrL1hchzGI005zyTG35deZeFDFHePRhI2H07GNOezfIMHJ0oK6IQlR3j39x8VUNsr4fjLxhEEgiKNyHh/kIkL8BqJolzdCWcvNAoOxEmyAb15U5Tz11VykaFl4Iz0412eSJZw4o++q/SCkSDh4p0fj6xZLqPqgPYCK/v9t6G7j1y1vrDR5sRmt5BpqDG2Xy1ShzIf5uemJXgj4XGG+QTY2oJLzCv/tT58HMTcg6Bmn5tDENFL59ovIAbHKyFx38O8lNrtxNksKHsM7whrQptQ1bPD+2dsChPr8SEl35fPFDaHSwvQfNfzak0Q0Un1IbwxKLh6Idw49Mi+0ejaNhBSsAcWr1tyvZYOXEOvIAFGusndGNB0qkQXPg36ayo v3SK6ib3 yvXU2BP1U6Y9Tp3rjO9d9VhMP9H5IFONbKQH36bOLTW+dFbY+IYd+8doWJZyb3tp9i/fa 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 Wed, 14 Feb 2024 at 09:44, Mike Rapoport wrote: > > On Thu, Feb 08, 2024 at 02:37:25PM +0800, Aiqun Yu (Maria) wrote: > > > > On 8/6/2022 3:22 AM, Mike Rapoport wrote: > > > Hi Vijay, > > > > > > On Wed, Aug 03, 2022 at 04:27:33PM +0530, Vijayanand Jitta wrote: > > > > > > > > On 5/9/2022 5:12 PM, Mike Rapoport wrote: > > > > > On Mon, May 09, 2022 at 04:37:30PM +0530, Faiyaz Mohammed wrote: > > > > > > > > > > > > On 5/5/2022 10:24 PM, Mike Rapoport wrote: > > > > > > > On Thu, May 05, 2022 at 08:46:15PM +0530, Faiyaz Mohammed wrote: > > > > > > > > On 4/12/2022 10:56 PM, Mike Rapoport wrote: > > > > > > > > > On Tue, Apr 12, 2022 at 12:39:32AM +0530, Faiyaz Mohammed wrote: > > > > > > > > > > This 'commit 86588296acbf ("fdt: Properly handle "no-map" field in the > > > > > > > > > > memory region")' is keeping the no-map regions in memblock.memory with > > > > > > > > > > MEMBLOCK_NOMAP flag set to use no-map memory for EFI using memblock api's, > > > > > > > > > > but during the initialization sparse_init mark all memblock.memory as > > > > > > > > > > present using for_each_mem_pfn_range, which is creating the memmap for > > > > > > > > > > no-map memblock regions. To avoid it skiping the memblock.memory regions > > > > > > > > > > set with MEMBLOCK_NOMAP set and with this change we will be able to save > > > > > > > > > > ~11MB memory for ~612MB carve out. > > > > > > > > > The MEMBLOCK_NOMAP is very fragile and caused a lot of issues already. I > > > > > > > > > really don't like the idea if adding more implicit assumptions about how > > > > > > > > > NOMAP memory may or may not be used in a generic iterator function. > > > > > > > > Sorry for delayed response. > > > > > > > > Yes, it is possible that implicit assumption can create > > > > > > > > misunderstanding. How about adding command line option and control the > > > > > > > > no-map region in fdt.c driver, to decide whether to keep "no-map" region > > > > > > > > with NOMAP flag or remove?. Something like below > > > > > > > I really don't like memblock_remove() for such cases. > > > > > > > Pretending there is a hole when there is an actual DRAM makes things really > > > > > > > hairy when it comes to memory map and page allocator initialization. > > > > > > > You wouldn't want to trade system stability and random memory corruptions > > > > > > > for 11M of "saved" memory. > > > > > > > > > > > > Creating memory map for holes memory is adding 11MB overhead which is > > > > > > huge on low memory target and same time 11MB memory saving is good enough > > > > > > on low memory target. > > > > > > > > > > > > Or we can have separate list of NOMAP like reserved?. > > > > > > > > > > > > Any other suggestion to address this issue?. > > > > > > > > > > Make your firmware to report the memory that Linux cannot use as a hole, > > > > > i.e. _not_ report it as memory. > > > > > > > > Thanks, Mike for the comments. > > > > > > > > Few concerns with this approach. > > > > > > > > 1) One concern is, even if firmware doesn't report these regions as > > > > memory, we would need addresses for these to be part of device tree so > > > > that the clients would be able to get these addresses. Otherwise there > > > > is no way for client to know these addresses. > > > > > > > > 2) This would also add a dependency on firmware to be able to pass these > > > > regions not as memory, though we know that these regions would be used > > > > by the clients. Isn't it better to have such control within the kernel ? > > > > > > If it is memory that is used by the kernel it should be reported as memory > > > and have the memory map. > > > If this is a hole in the memory layout from the kernel perspective, then > > > kernel should not bother with this memory. > > Hi Mike, > > > > We've put effort on bootloader side to implement the similar suggestion of > > os bootloader to convey the reserved memory by omit the hole from > > /memory@0{reg=[]} directly. > > While there is a concern from device tree spec perspective, link [1]: "A > > memory device node is required for all devicetrees and describes the > > physical memory layout for the system. " > > Do you have any idea on this pls? > > I'm not sure I understand your concern. Isn't there a /memory node that > describes the memory available to Linux in your devicetree? That was the question. It looks like your opinion on /memory was that it describes "memory available to Linux", while device tree spec defines it as "physical memory layout". > > > [1] https://github.com/devicetree-org/devicetree-specification/blob/main/source/chapter3-devicenodes.rst > > > > > > And I'm not buying "low memory target" argument if you have enough memory > > > to carve out ~600M for some mysterious clients. > > > > Just for your information, for low memory target, the carve out can be more > > than ~60M out of 128M in total. > > If saving ~1M of memory map is important, hide the carve out from Linux > entirely. > > > > > Let me know your comments on these. > > > > > > > > Thanks, > > > > Vijay > > > > -- > > Thx and BRs, > > Aiqun(Maria) Yu > > -- > Sincerely yours, > Mike. -- With best wishes Dmitry