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 1A5F8CA0ECC for ; Fri, 30 Aug 2024 01:10:10 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 6FAEB6B007B; Thu, 29 Aug 2024 21:10:09 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 683C06B0082; Thu, 29 Aug 2024 21:10:09 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 4D6516B0085; Thu, 29 Aug 2024 21:10:09 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id 2C7A66B007B for ; Thu, 29 Aug 2024 21:10:09 -0400 (EDT) Received: from smtpin18.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id AAFA716100C for ; Fri, 30 Aug 2024 01:10:08 +0000 (UTC) X-FDA: 82507130496.18.1B686B1 Received: from mail-pf1-f181.google.com (mail-pf1-f181.google.com [209.85.210.181]) by imf26.hostedemail.com (Postfix) with ESMTP id C7D54140012 for ; Fri, 30 Aug 2024 01:10:06 +0000 (UTC) Authentication-Results: imf26.hostedemail.com; dkim=pass header.d=rivosinc-com.20230601.gappssmtp.com header.s=20230601 header.b=moFetPCz; spf=pass (imf26.hostedemail.com: domain of charlie@rivosinc.com designates 209.85.210.181 as permitted sender) smtp.mailfrom=charlie@rivosinc.com; dmarc=none ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1724980161; a=rsa-sha256; cv=none; b=WY05eToHS94EiFYxbbnxq6K/SdU4ExIq5X91auXoDTBOGo6RT30dwREdxTUoSX4lhZUuj8 64dQ35o4fAUoBIGCzkFUg94XBP+C/9qmco4Npqi/6MherkoHIDZPKzkpape1MkUSw3S9B1 1KeqhsKLWF8W+NR5yQyD/uY+Sg4Ynnc= ARC-Authentication-Results: i=1; imf26.hostedemail.com; dkim=pass header.d=rivosinc-com.20230601.gappssmtp.com header.s=20230601 header.b=moFetPCz; spf=pass (imf26.hostedemail.com: domain of charlie@rivosinc.com designates 209.85.210.181 as permitted sender) smtp.mailfrom=charlie@rivosinc.com; dmarc=none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1724980161; 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=CwoqNPnm0PFMKEw2mojvKZssW8GhVCDsDfQmuaD4p/M=; b=F9td3HEeTMKrX4QvHcq8AsMmqHxCSgdr7b86+yjSISwG2G71cdnlyzy093R6RzGBajp3zK h8/I3VaAOKolF7gRF5Q/k6UPU1M7rCvWuBtHl3RODBTEBPUpOuTQ8ukqqdrpxRC70irpLp 8pqURTHig4CwYBho6GPLDRkiLa/3zgI= Received: by mail-pf1-f181.google.com with SMTP id d2e1a72fcca58-7141d7b270dso1041618b3a.2 for ; Thu, 29 Aug 2024 18:10:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rivosinc-com.20230601.gappssmtp.com; s=20230601; t=1724980205; x=1725585005; darn=kvack.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=CwoqNPnm0PFMKEw2mojvKZssW8GhVCDsDfQmuaD4p/M=; b=moFetPCz/8GtaNpt+tz+HClWCyZVnOzAVdshoLN6rmEoZezEJoACKo5HRQwEgtRw7e bQizb8sakoMr6qIaeqgxnQwwcsBIC5RGPEG8cHfkG46oY/2UIfFJKsGLaUPMSyPel0fV D+sTFTth7QsrsqzLp7q1jLUPvpx/GscPKAi/rENDln2j7kHSgwIv655qTzcAxE/pyT/y Ai/UZlcyuViD2V1Y8fYRUOh205JoTCSLIYF7uU4pV7zxdDu1W2RBmKmpBp/CZuDnfV98 RX6sz0Vz79iF1gA9jNzVdjy2gBZsYNwFZG7gk6+fI1+XJXE5mekwOkofp0JcVXgucnAo 17mw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1724980205; x=1725585005; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=CwoqNPnm0PFMKEw2mojvKZssW8GhVCDsDfQmuaD4p/M=; b=pQvMMgUtq07g5iyrdofhym9qa9f2y3YPFr9zUq9XnfzwflZYq4jIKBczQxXVgeyObU q93quIvPh64WyjFOscqmyAVSOuvzrR4uQfbD8a0WtJkzDdqd2O09hizpHgeERV8gyI9F WD5nbMQX4EwIsX6APS0i+tzQj9D+lmyBvX/AjmOAj5AGtV7Czd594vrrsTEEE4jlEv2E DELV84KTndv2CP+qSZluTs+T8g5ufb3yW79FxjFqtqHcXADKjT9u8Gznzj2ePvxzlPRu YEUDPad0wBjDj10Gs51LvCfUZQPYbuifrLsvxL6d+l0Fhm4qEGVzR0JE+TMeX2O3pOzm Jdsg== X-Forwarded-Encrypted: i=1; AJvYcCUSJvFRNQ2y393kK8j7b4BZyJPjH2oEAlrlM8Quzh4gpikzoUYDkC7qpTj+NY3iWEgQ1N9l11vpVg==@kvack.org X-Gm-Message-State: AOJu0Yw6VAqZWvxsS0YBYFVGAUKVCyOZ+ToCWkmoM+K+i2BNXUIIjPbI mJcpKdw5ouAnyGkKcRx8uV4gEDmEyayrKmKohhkxcV4Iod4gPsdBX+4FvF2Hw+s= X-Google-Smtp-Source: AGHT+IHjWR5hohyc19lNozH4CTnGNOicvRPszOH5PvlKyMQFSKFQKAXiGMUabKYrMEs/kL3dRfpZ8w== X-Received: by 2002:a05:6a21:3943:b0:1c0:f216:7f20 with SMTP id adf61e73a8af0-1cce10ec619mr4946320637.49.1724980205096; Thu, 29 Aug 2024 18:10:05 -0700 (PDT) Received: from ghost ([50.145.13.30]) by smtp.gmail.com with ESMTPSA id d9443c01a7336-205152b1326sm17228115ad.35.2024.08.29.18.10.01 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 29 Aug 2024 18:10:04 -0700 (PDT) Date: Thu, 29 Aug 2024 18:10:00 -0700 From: Charlie Jenkins To: "Liam R. Howlett" Cc: Dave Hansen , Arnd Bergmann , Paul Walmsley , Palmer Dabbelt , Albert Ou , Catalin Marinas , Will Deacon , Michael Ellerman , Nicholas Piggin , Christophe Leroy , Naveen N Rao , Muchun Song , Andrew Morton , Vlastimil Babka , Lorenzo Stoakes , Thomas Gleixner , Ingo Molnar , Borislav Petkov , Dave Hansen , x86@kernel.org, "H. Peter Anvin" , Huacai Chen , WANG Xuerui , Russell King , Thomas Bogendoerfer , "James E.J. Bottomley" , Helge Deller , Alexander Gordeev , Gerald Schaefer , Heiko Carstens , Vasily Gorbik , Christian Borntraeger , Sven Schnelle , Yoshinori Sato , Rich Felker , John Paul Adrian Glaubitz , "David S. Miller" , Andreas Larsson , Shuah Khan , Alexandre Ghiti , linux-arch@vger.kernel.org, linux-kernel@vger.kernel.org, Palmer Dabbelt , linux-riscv@lists.infradead.org, linux-arm-kernel@lists.infradead.org, linuxppc-dev@lists.ozlabs.org, linux-mm@kvack.org, loongarch@lists.linux.dev, linux-mips@vger.kernel.org, linux-parisc@vger.kernel.org, linux-s390@vger.kernel.org, linux-sh@vger.kernel.org, sparclinux@vger.kernel.org, linux-kselftest@vger.kernel.org Subject: Re: [PATCH 00/16] mm: Introduce MAP_BELOW_HINT Message-ID: References: <20240827-patches-below_hint_mmap-v1-0-46ff2eb9022d@rivosinc.com> <4219f619-4b32-40bc-85b8-cb11d76fde98@intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Stat-Signature: 9repbh5n4ms465shr7axtconb4ciakmf X-Rspamd-Queue-Id: C7D54140012 X-Rspam-User: X-Rspamd-Server: rspam10 X-HE-Tag: 1724980206-968571 X-HE-Meta: U2FsdGVkX19TIxjM1kzpw3sHVeB0T4e3rVyUAL8ZG0fxlWfKN2VGSUkNYN2Tel1udb7L/DK2qsO1w1pQoc34gKZWBSeKI2Q+432hxdE6WGNkOn2LG3QpoVuKfsNeN+5CS3A3H73CHn/xNKC/MFnmn/N7aEfCP3NeD/Yu/0e9PQv9Ov1pk6MHLkA7k3e2mKeWiWv6lvHP5t1D/FXWzycwMXCuR0z8HGDHYFLkspXLw+NO461jKtLD+PPeN/AoicNK97qxFUTc5CPTZnyRjctSbs42jC2UjRVQX7ZoK2nojBHkWXINLafw/LAtOdZx1nMm89XN+unmUyqhE1v8UkKcMxNASoDNGjkwyTXt3G1hDLHXO5X6LKPRXZ2xMljZODNa6VUQaMkGOTmC1+iq7OArBcS1+sEFguxrsJkunRicZRezRsxU4KstBiMwIZ97KdJSkxSfFVsdFvbXwT69xyAe+sGLdeMP47ORYj2u2dyyxJA1YLPvuKJLODgF/Sw8DgUciUB75FDlk02U1CtKyJjkDlUwCJkKhKkzAITCmktGS9q7twOygmYHp5x5Sj/DXIWCeF4vwiEE9b1wL7cNnhEawQNqyXgdpKm0MeiTfi4OhRNoBIwOUqJAXHYNSXlceMmTh4uaqEqezEGJGu2Yse/+heY9K7+1Rev9MJUpUL5wYP3CKz7co1WM4Yol4aXGC4ANSIFD/Fq1swpoKpReQ82jKZtPlHh2ymE0TJsjFsX6qKL2O8LIzQ05HU6I+7OFchhPRGPusqa34ANaQc3MiH8mTy1Bh5NiYTYLyBQVDpql0b6N5WlQsfkstpmV1KiW/B/NJVKBDH8XcnHiXHAEdB7mMXEnkw1mpshyngHXiYU04pJtbyINWrtoksx+zjjwj6ejEDzogvCqR157EiRFtF72x1DOL9Gy/QmmWwFR2FJfpo+ttnwVag6Eq/jUiNdAE/6fNRhvf/ZjFtWUmYnpOop EW4BtXy5 JLd4WxEZ1uLh9hTzoj8Jf/lC/hu1hk7sfbmJgc/VOzOsVXSSTBvQcPuzcjd1KDiGzgmHjNOp5aAZojQvRnUPvY42v2C6IJSX35Q1gdvj+t4HoJpMnB9paMsZ+Y/meda3TIkQ6xncv2m5Ch/lNxEmC2VPSnm4Rwn0l0Nvmvv0RzfNCbYV8Zr0K2Bf1HUy7HrMYrqxx8e0oHm1D+dBziBL5BkhIeNq2tPBINuiv3GzlkYl26VJEU8TkNJl0sPjDUyv64BiQCfP/GMgvWleKWyzMIgSYZis5OoVb18FGVUb4T9KMcnexJKWymqkZcjuk522TAsRl8Tknk8PnOI+xVwI3nIqMmoc34oRM0SShbAGtXpXnwYaqHOn4uEKBIFozJL/ELg55aag4ZNEuPN63TOq1HaXsDwv82Na3Cv1VHcDB+nb+Wnskh7l2Evka9Q== X-Bogosity: Ham, tests=bogofilter, spamicity=0.000003, 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 Thu, Aug 29, 2024 at 03:36:43PM -0400, Liam R. Howlett wrote: > * Dave Hansen [240829 12:54]: > > On 8/28/24 13:15, Charlie Jenkins wrote: > > > A way to restrict mmap() to return LAM compliant addresses in an entire > > > address space also doesn't have to be mutually exclusive with this flag. > > > This flag allows for the greatest degree of control from applications. > > > I don't believe there is additionally performance saving that could be > > > achieved by having this be on a per address space basis. > > > > I agree with you in general. The MAP_BELOW_HINT _is_ the most flexible. > > But it's also rather complicated. > > There is a (seldom used?) feature of mmap_min_addr, it seems like we > could have an mmap_max_addr. Would something like that work for your > use case? Perhaps it would be less intrusive to do something in this > way? I haven't looked at it in depth and this affects all address > spaces as well (new allocations only). > > There is a note on mmap_min_addr about applications that require the > lower addresses, would this mean we'll now have a note about upper > limits? I don't think that's a viable solution because that would change the mmap behavior for all applications running on the system, and wouldn't allow individual applications to have different configurations. > > I really don't understand why you need this at all, to be honest. If > you know the upper limit you could just MAP_FIXED map a huge guard at > the top of your address space then do whatever you want with those bits. > > This will create an entry in the vma tree that no one else will be able > to use, and you can do this in any process you want, for as many bits as > you want. Oh that's an interesting idea. I am not sure how that could work in practice though. The application would need to know it allocated all of the addresses in the upper address space, how would it be able to do that? > > > > > My _hope_ would be that a per-address-space property could share at > > least some infrastructure with what x86/LAM and arm/TBI do to the > > address space. Basically put the restrictions in place for purely > > software reasons instead of the mostly hardware reasons for LAM/TBI. > > > > Lorenzo also raised some very valid points about a having a generic > > address-restriction ABI. I'm certainly not discounting those concerns. > > It's not something that can be done lightly. > > Yes, I am concerned about supporting this (probably forever) and dancing > around special code that may cause issues, perhaps on an arch that few > have for testing. I already have so many qemu images for testing, some > of which no longer have valid install media - and basically none of them > use the same code in this area (or have special cases already). I think > you understand what we are dealing with considering your comments in > your cover letter. It is definitely not something to be taken lightly. The version 2 of this is completely generic so that should eliminate most of the concern of "special code" on various architectures. Unless I am misunderstanding something. - Charlie > > Thanks, > Liam