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 3BDCCC3601E for ; Mon, 7 Apr 2025 11:50:26 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 53F1C6B0005; Mon, 7 Apr 2025 07:50:25 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 4C6BC6B0007; Mon, 7 Apr 2025 07:50:25 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 340CE6B000C; Mon, 7 Apr 2025 07:50:25 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id 103586B0005 for ; Mon, 7 Apr 2025 07:50:25 -0400 (EDT) Received: from smtpin30.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id 04DFD1C750A for ; Mon, 7 Apr 2025 11:50:24 +0000 (UTC) X-FDA: 83307080010.30.A9356C7 Received: from mail-ua1-f47.google.com (mail-ua1-f47.google.com [209.85.222.47]) by imf28.hostedemail.com (Postfix) with ESMTP id DFC0FC0003 for ; Mon, 7 Apr 2025 11:50:22 +0000 (UTC) Authentication-Results: imf28.hostedemail.com; dkim=none; spf=pass (imf28.hostedemail.com: domain of geert.uytterhoeven@gmail.com designates 209.85.222.47 as permitted sender) smtp.mailfrom=geert.uytterhoeven@gmail.com; dmarc=none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1744026623; 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; bh=i4+pLFMxzNKF7wuYEtBPsrpqj7a4qDgMwXzKwK/DCEs=; b=mdyzekkcaOch8UnmYJd+hmL+rQ6JiNLTwAutZelXdvRDFSNFEtFp07oGpM4l9meYQPchFk ETPgBgFjPRPxF+s+/jAss63taUONChRqESzsFHXDTtuoQvHuTZ1J6T+2E5vmkawUHZ/Q84 r8mZLuL8OFEWVuAqp02/ibAN4bmh3iI= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1744026623; a=rsa-sha256; cv=none; b=jMDXP6hMolVFioQHGrdHVwC+I0RBS2l6yFbBjcwOpvu1VJXz6AxBnLNRQBEE89gibYSe8l 0yyEgnRvNfkV3BL1VG83WGvxdkt6bPcV1FO2+CQeQJ5/if0VpTiydYMOlHFvnNr/SGVzGL xhM+u8CKVsrMrjT+FZlqtuvlNBJaFbI= ARC-Authentication-Results: i=1; imf28.hostedemail.com; dkim=none; spf=pass (imf28.hostedemail.com: domain of geert.uytterhoeven@gmail.com designates 209.85.222.47 as permitted sender) smtp.mailfrom=geert.uytterhoeven@gmail.com; dmarc=none Received: by mail-ua1-f47.google.com with SMTP id a1e0cc1a2514c-86715793b1fso1785160241.0 for ; Mon, 07 Apr 2025 04:50:22 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1744026620; x=1744631420; 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=i4+pLFMxzNKF7wuYEtBPsrpqj7a4qDgMwXzKwK/DCEs=; b=oYNSjSJww2PvNhDRPwzkvtiHkUuGmh3f+WGJWOqv73Zuej/jRBP+XwVoJsdmCQxwab KeKOwDjDyI5L3gIn07n88vkwlj+FS/c2nIuhHiV+LGut8QGsCkeBc20dZQrQUQU+Hhxw 91i6VCM+DPKpvndHlPXSivRo+UcSnVANRMqRh1PJ/wzAOZn72CJhiRpYoVzGTVX6QEpB lt0gYIvekwlnUANe1Gy7dcU3RKv1AQElyd3PgXT+7YKQ+cdWFgPrFKeaRI+fb0AeOWgv nCX7cp17P2NDPIAgXlTfouAXb/P8B9EPCFBjLLu5tn/kmatIXABql8/DkLfqeIO+LbOr 5N9w== X-Forwarded-Encrypted: i=1; AJvYcCXHKE1qn/KhjHSXrp5eDtTJ3BThR50YTr60QXBVZJdX62lOe7adNJuTAJwpSD8ylrpjEs7tbc+h4g==@kvack.org X-Gm-Message-State: AOJu0Yz8rwmaW/u2U0qtIgU2kHcNmJfnY0YgudxooTxy4wnfjQGwrqKn Mx24jDoGNso4Yx/PF8o9VVAgdyelNCxwGzp/PTqKpD6764jSoveU7ESg51Du X-Gm-Gg: ASbGncszT9FklkhB5WRRUJ7uuEVhhWwygIZVTR122tEYW7jeF2PS6krPVB8ROmSQd+8 2ujjgFD1bom/CUMNGfrW9TMgQZBW8LGjUGLruGVeXYrrTkC4AiIZeCULpQD7uc4hikDXZ4ccQ4t aToIp3fDsQXSZGOfpYcmAJ6nZT0Rfn8f/DWni7WZSbT3uCFkiogUMEfeJ3Jya5Vp7/TIUdidnha Rv4s0jcT+6J6JlI3xBkEmAu2MfGDIydv/KvPgggBksQh/mj6RDonL6Oc7AjvGNGvEUn7kML3HtR Nbf9fgNRQulbVhfGklCFcinyUSSieSgrciD6Hi9Uny307MZ+ETU+STmxk7dmkTWmPQcqCezKj32 w0ybxqWE= X-Google-Smtp-Source: AGHT+IHJXnXetq7l3zVx0ASTBuUqKvGRPv9cN2ViSmdyTpbt8ANIMHZ0hf1R/WZ8pw3gFgIwMp6IVg== X-Received: by 2002:a05:6102:3ed0:b0:4c5:1bff:4589 with SMTP id ada2fe7eead31-4c8554b008bmr8089414137.22.1744026620465; Mon, 07 Apr 2025 04:50:20 -0700 (PDT) Received: from mail-ua1-f43.google.com (mail-ua1-f43.google.com. [209.85.222.43]) by smtp.gmail.com with ESMTPSA id ada2fe7eead31-4c84943cafasm1918205137.15.2025.04.07.04.50.19 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 07 Apr 2025 04:50:20 -0700 (PDT) Received: by mail-ua1-f43.google.com with SMTP id a1e0cc1a2514c-86d30787263so1948868241.1 for ; Mon, 07 Apr 2025 04:50:19 -0700 (PDT) X-Forwarded-Encrypted: i=1; AJvYcCUHecgdKB3nPbYeS3rqe+IYMz/LZxnCOlZJiLPz15u4A4syw3LIUpztwBIUPwOIxUCgT12Clg7MXA==@kvack.org X-Received: by 2002:a05:6102:f86:b0:4bb:eb4a:f9f2 with SMTP id ada2fe7eead31-4c8553aea85mr9265953137.9.1744026619724; Mon, 07 Apr 2025 04:50:19 -0700 (PDT) MIME-Version: 1.0 References: <20250228182928.2645936-1-fvdl@google.com> <20250228182928.2645936-3-fvdl@google.com> In-Reply-To: <20250228182928.2645936-3-fvdl@google.com> From: Geert Uytterhoeven Date: Mon, 7 Apr 2025 13:50:08 +0200 X-Gmail-Original-Message-ID: X-Gm-Features: ATxdqUH7PH4vq6Q_RgYLRrVLiKbH_NIvyy9Ay2B6TtCJJJg26LiT8zWJ4O0OrhI Message-ID: Subject: Re: [PATCH v5 02/27] mm, cma: support multiple contiguous ranges, if requested To: Frank van der Linden Cc: akpm@linux-foundation.org, muchun.song@linux.dev, linux-mm@kvack.org, linux-kernel@vger.kernel.org, yuzhao@google.com, usamaarif642@gmail.com, joao.m.martins@oracle.com, roman.gushchin@linux.dev, ziy@nvidia.com, david@redhat.com, Arnd Bergmann , Linux-Renesas , Linux ARM Content-Type: text/plain; charset="UTF-8" X-Rspam-User: X-Rspamd-Server: rspam10 X-Rspamd-Queue-Id: DFC0FC0003 X-Stat-Signature: j88dyj3u7kihbqrcjugq9ujugjbm9wqu X-HE-Tag: 1744026622-150149 X-HE-Meta: U2FsdGVkX18IbVobIYvtJrcg+yf8+wKi0DUW+49cUj+YtByAmM0ZGfThwd7MN4gjMWQ1ii+PtzVEJ8ipTKYbqgwU2tAF0g98x8Yop39RpJpwjEakSbANTu6z+F+uRURTib09Ohe+Z9kdDEiA/ka86LHWHIYWRJuPSBJbhNVFpCOrAesABrEycKMWh+bJ8ymf3h3qCGQ1Lu990Aye25GdxI1xl125ytbhL4uaGoyNIA02By5zb7991ujVLSf2CeGXCHJ9A8cwAzRn1VTAfHqAvZRD35TtxlTlPKCU89S3m1VVdYM1eDc+PBh1tp8HypSp9dSpVGhHjjcXgNtySX4rtmkmyIc3FhrLb/HQ5y93Z65GobfDjBVhbf57Un3A0idsaL30F0FmmY/SAR+g4+5ZJIgO7p5wgkLXQaHHIxpWb/kDG2ge+2HVNujO6xklm/bjX1oG1sGl+17wrhwsUYXM0YG+ukvUogsfkcPAy3ZV9CTTtXz9/7jsbRA4NMKNfG+8usIgAKoPYvUimBCHExhpcxZ7r/7q47WOIYk9qbo+plCp0sYQuPRHqYK73iqreXDyWRigEpN3wPBYHDCDWg1JqjO7D1mQcgOaxVfOyAt6TGdq64Yz5oLJAI4iRRBx43vmhmHoqyn0vHvwBZB6pb3q5l7U9dfpGnybenQLlYO0YlL922RNQqmgUlKeMhH/81EkUbaw1zbYaHyyJu58YC/O2AMN3AJ6ShvGqSozlg6sJqGzXPOLrONT8+VItbD3l4BLXmh2Wh5sz2Vxc0sy0Tp21hIiip6kJzIoC/6/ed781XYwWcfcM5dZHyEPauxv00EKHY7hxbpyamapZYwwnC+TGN3uTP95u+M6vzwoNXlw9+liGeTLhhnDRp7MvmGAlE7LpMOKXTG5n/CjakyxHl26yJilNai1u8cPiMl088d/6CHvNuN6b/YLXoMRz8mdb8jJf5gEe44rUWqAXkZycnf QMu9DR2b NcmhiprGVYBqUe5G7q3stEYkYYlbHK1ualBieyKAonfjL23rsjbFO5LJlwuVJFuv/eIRoVRcazGxQU9moXIIWSLWWKMO3+UwMxX/zH6gEQsXFzToWvQkipKt5mIUcIHGIz16aJRLP667c43aTUOxoVrRQ+MUp22L6k/9tLK1SNYsk7bhJorFqxZEnzoeRMjrSiROHWtZ4Invu2GK+4dFy6u8/zh99cPCiLjrFfigoM5jMlsmtLWGPpSBvLZLBXxUCzMTMy+cWDniBfRpaqfWgCSVEmEew+TOlghas1EfBt/6rLzpUOB5qaTCpLRRxA82E0HzhdK6GQovaJtKoqwUFUiCnT4Te/yeo7DmzGmtRNSaTyLNINE9WDoiKMI7QWqINgaw1DNHDQptRnGZKLXgPBoqGyAFvBjzJLu+JNazucxthI+Y= 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: Hi Frank, On Fri, 28 Feb 2025 at 19:30, Frank van der Linden wrote: > Currently, CMA manages one range of physically contiguous memory. > Creation of larger CMA areas with hugetlb_cma may run in to gaps > in physical memory, so that they are not able to allocate that > contiguous physical range from memblock when creating the CMA > area. > > This can happen, for example, on an AMD system with > 1TB of memory, > where there will be a gap just below the 1TB (40bit DMA) line. If > you have set aside most of memory for potential hugetlb CMA allocation, > cma_declare_contiguous_nid will fail. > > hugetlb_cma doesn't need the entire area to be one physically > contiguous range. It just cares about being able to get physically > contiguous chunks of a certain size (e.g. 1G), and it is fine > to have the CMA area backed by multiple physical ranges, as > long as it gets 1G contiguous allocations. > > Multi-range support is implemented by introducing an array of > ranges, instead of just one big one. Each range has its own bitmap. > Effectively, the allocate and release operations work as before, > just per-range. So, instead of going through one large bitmap, they > now go through a number of smaller ones. > > The maximum number of supported ranges is 8, as defined in > CMA_MAX_RANGES. > > Since some current users of CMA expect a CMA area to just use one > physically contiguous range, only allow for multiple ranges if a > new interface, cma_declare_contiguous_nid_multi, is used. The other > interfaces will work like before, creating only CMA areas with > 1 range. > > cma_declare_contiguous_nid_multi works as follows, mimicking the > default "bottom-up, above 4G" reservation approach: > > 0) Try cma_declare_contiguous_nid, which will use only one > region. If this succeeds, return. This makes sure that for > all the cases that currently work, the behavior remains > unchanged even if the caller switches from > cma_declare_contiguous_nid to cma_declare_contiguous_nid_multi. > 1) Select the largest free memblock ranges above 4G, with > a maximum number of CMA_MAX_RANGES. > 2) If we did not find at most CMA_MAX_RANGES that add > up to the total size requested, return -ENOMEM. > 3) Sort the selected ranges by base address. > 4) Reserve them bottom-up until we get what we wanted. > > Cc: Arnd Bergmann > Signed-off-by: Frank van der Linden Thanks for your patch, which is now commit c009da4258f9885c ("mm, cma: support multiple contiguous ranges, if requested") in v6.15-rc1. After this patch, the printed base address becomes zero on several Renesas arm32/arm64 platforms: - Koelsch (R-Car M2-W): -cma: Reserved 64 MiB at 0x7c000000 on node -1 +cma: Reserved 64 MiB at 0x00000000 - Salvator-XS (R-Car H3 ES2.0): -cma: Reserved 128 MiB at 0x0000000078000000 on node -1 +cma: Reserved 128 MiB at 0x0000000000000000 - Gray Hawk Single (R-Car V4H): -cma: Reserved 128 MiB at 0x00000000b8000000 on node -1 +cma: Reserved 128 MiB at 0x0000000000000000 None of these have actual RAM at address zero. As I haven't noticed any other impact on system operation, I do not know if this is purely a cosmetic issue, or if it can cause real problems. Thanks! Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds