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 8EC9DC54798 for ; Thu, 29 Feb 2024 19:21:39 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id CD4BF6B0092; Thu, 29 Feb 2024 14:21:38 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id C855B6B0098; Thu, 29 Feb 2024 14:21:38 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id B4CE16B0099; Thu, 29 Feb 2024 14:21:38 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0014.hostedemail.com [216.40.44.14]) by kanga.kvack.org (Postfix) with ESMTP id A2BE46B0092 for ; Thu, 29 Feb 2024 14:21:38 -0500 (EST) Received: from smtpin27.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id 336A3140458 for ; Thu, 29 Feb 2024 19:21:38 +0000 (UTC) X-FDA: 81845810676.27.988F696 Received: from mail-pf1-f175.google.com (mail-pf1-f175.google.com [209.85.210.175]) by imf22.hostedemail.com (Postfix) with ESMTP id 548D0C0016 for ; Thu, 29 Feb 2024 19:21:36 +0000 (UTC) Authentication-Results: imf22.hostedemail.com; dkim=pass header.d=dabbelt-com.20230601.gappssmtp.com header.s=20230601 header.b=AQFbnF9k; dmarc=none; spf=pass (imf22.hostedemail.com: domain of palmer@dabbelt.com designates 209.85.210.175 as permitted sender) smtp.mailfrom=palmer@dabbelt.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1709234496; 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:dkim-signature; bh=tI0BeeYqM9dH4CtDmNU5Z89KyVB0ENS6fdLlu9zwgwk=; b=kXUTzylApEQuebP+OAuW58PlRK2ITQE8gou2Ckt2Y/lOpty2uQ9gS2dBYkNkT1TAUqtVUx TsR9GmRN3TQV41h5Fa35cyf61DEOLE1DGslZmd9/ikkJn0Tl9tGbKM5dAyzIfiwvSyz4YS z4ubZ9wLMRcBuqF/oSQERr2sGmCGPec= ARC-Authentication-Results: i=1; imf22.hostedemail.com; dkim=pass header.d=dabbelt-com.20230601.gappssmtp.com header.s=20230601 header.b=AQFbnF9k; dmarc=none; spf=pass (imf22.hostedemail.com: domain of palmer@dabbelt.com designates 209.85.210.175 as permitted sender) smtp.mailfrom=palmer@dabbelt.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1709234496; a=rsa-sha256; cv=none; b=tvUl0bEes8FtiXgTK0+Bp6OiMgTGaAXx2LMBI81EZB4RFsh5Bb8ahDpgmnIotyMVKr4v40 oKc8dp1IlE0+Du2s9pnJabgRLk/L+Wo8pA65W4jspXe+G3vVkvr7aUk5V4uUct4Qeqww9Z aVN7lCluFYwMszEnENd/pvcMufGGLB0= Received: by mail-pf1-f175.google.com with SMTP id d2e1a72fcca58-6e459b39e2cso1885340b3a.1 for ; Thu, 29 Feb 2024 11:21:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dabbelt-com.20230601.gappssmtp.com; s=20230601; t=1709234495; x=1709839295; darn=kvack.org; h=content-transfer-encoding:mime-version:message-id:to:from:cc :in-reply-to:subject:date:from:to:cc:subject:date:message-id :reply-to; bh=tI0BeeYqM9dH4CtDmNU5Z89KyVB0ENS6fdLlu9zwgwk=; b=AQFbnF9kATGgc1QdBVygv4lSgbz7k+NHXEPoGHQaNtx32Q8WuLa5pvCfB5qkMGg0zK zdtMUMAWbaqAV5GsaYtL6Y/in2e0h9gsBeF7p+qfVqOBxDh0aK9FAe7CvcNlfLXilU54 VBiQkxpIfZrJL6f0LA9V1ElpZcFUpiIzajZecrCWGOsXnNbUJfpSAM/MJm3m/qx6HRnl KthA3aW5pLGQuX0u7VYY5g/0JKpt0ncHnq9hAGQIPmNbZpJeu4DCQuLcbskVxMQ0FSpA 4mL6RgKhd3q6us1fseKMwuWveiioIA1m/m8n28Lsqzk08gcLo842y+BwyOzL1Qh1I+wP VIng== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1709234495; x=1709839295; h=content-transfer-encoding:mime-version:message-id:to:from:cc :in-reply-to:subject:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=tI0BeeYqM9dH4CtDmNU5Z89KyVB0ENS6fdLlu9zwgwk=; b=DNLjMEfN34doEVTa9rXA90ng41Yio48olkLgjbDGbT9EqV6SWxFICnZTBeO5DsjanX e7GGNRis+GW/oDEU1NwMePI6y38xEPwlk1dBQEDiFqqo4phAW5nifKu6qB+7Np5Broli QMz5YSAqjw7kW3X8Dm5Lc40DE2VMRTdv4JAWYLh6nnt7/2brZTTWkmtRjkxgcp+mCsG/ TdkKnRZnxTO2rpTm/sE68DEvIjxI/B9GJPBsTlb6+rt9KckY+QigN/AtFkKFm1bksfKo IzALeGLj70SvR6GhQExAOZZMfLUoyPOinX71Ai++mtm6xMqD008lY65ILbh/q9/BHJgv v6wg== X-Forwarded-Encrypted: i=1; AJvYcCVSq+5EtlVZGY2H0Ds/GRCTfoaqAljzxVRrfeuWbwxfUsf0YmSRIlnDd8zAAxQvUzbfSzcRAkZQMbgREfbuonBqaU0= X-Gm-Message-State: AOJu0YxWqA25xCzz7KVm14QRAh5uqxE4uJjB9wRgcgpO4bmDNK2avIIH feP3xllSdqrBqNnIfMsUUFxsh1Te9XdolOANlDM1VyFpYeP5vkDMG1LgttlUElI= X-Google-Smtp-Source: AGHT+IEb+gGTWSZJgyAaR/j/macgR4G7Qn8rFIkQpEZb0vtMqMn8yLy4/Fk0QWniPKOilz8fvl9fwA== X-Received: by 2002:a05:6a20:e616:b0:1a1:209e:99da with SMTP id my22-20020a056a20e61600b001a1209e99damr4015579pzb.28.1709234494948; Thu, 29 Feb 2024 11:21:34 -0800 (PST) Received: from localhost ([50.213.54.97]) by smtp.gmail.com with ESMTPSA id e6-20020aa798c6000000b006e4f18784cfsm1625915pfm.124.2024.02.29.11.21.34 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 29 Feb 2024 11:21:34 -0800 (PST) Date: Thu, 29 Feb 2024 11:21:34 -0800 (PST) X-Google-Original-Date: Thu, 29 Feb 2024 11:21:32 PST (-0800) Subject: Re: [PATCH v2 0/3] RISC-V: mm: do not treat hint addr on mmap as the upper bound to search In-Reply-To: CC: cyy@cyyself.name, alexghiti@rivosinc.com, andy.chiu@sifive.com, Charlie Jenkins , Conor Dooley , guoren@kernel.org, jszhang@kernel.org, linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, linux-kselftest@vger.kernel.org, linux-mm@kvack.org, linux-riscv@lists.infradead.org, Paul Walmsley From: Palmer Dabbelt To: cyy@cyyself.name Message-ID: Mime-Version: 1.0 (MHng) Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Rspamd-Queue-Id: 548D0C0016 X-Rspam-User: X-Rspamd-Server: rspam04 X-Stat-Signature: 118p38r6fgu51dhihorizmyxcwztz4z1 X-HE-Tag: 1709234496-779451 X-HE-Meta: U2FsdGVkX1/dE2nGjyms0JmnCNLoCOW93vb/NVOipdaeQJtRwi+YcG6Sb1o0dT5DjLqPk2oub3CNkzeoAY4LNU3sjidur6NuIYqCpCXIrn62k7i++P6z/3smd0ppZcx92P23DWa5S+qcXXCHGlvc0VA1SydttyPtaItdRZXNJgDMvcVqd7u+58Twgl3RP25XQ+9323+a6y7Xyy7C2ef5lboeBqJzCt/GdMz3RyBJLADuBkTgQwe44BWF3wzvVJk+GQ3urikQGJFc7J/OKbcoeVDjuih+imiDFL6wOvJB1h+VJ5Vqs1YCuakhXN5g8JxEAvMbXko9WkwEx8/8j1hk3eTtQvsmni2jPeWl5cvrH55+ImEUl/PJ+sxY2uY0XUl88P5fe5iUQB4IBvgCAsUcogf9/XSNgmJA8cpDY/8PeFloNgJQX1Qw0mg/cPsYVTRINMvrjqGvpeqixfuDEqLmpHIqwTRjxQaB3PTev58TKO2i4iJ7k5i83xmC+pYmmZ3TCkDb0pasCgO4fRiw4+liJc3eQQvp+qnrorVWxRzcL+Zv7TuLW06UY/915R1tqeaDlzO5j27+vpmPqREFjcqWhAye7fpeLYRC4Pi9dKn4QVtu1hzmGzQzT5DNSer4yoEQ//0CpR1I9Z1wRtLF1Wpe48+FZDddSL0Kv/EqkzHoz+xJgG0OObN+2Sz8IEN/One0rimouTCCnHXiONIdRGaxssmFAgq22eHyMkJHa54I6bo9MKnwg5GGrvTkjYlyrR0eahlsB77MzmRXcvznyUu0H2OkpTwp/2fTNeyYNcpw8UDy2CYZcad6VokdjbrvE819uc58co8IUl19KmNBJteAtjOPQQ0r7LoLxuKFofbhGCFQH+kjUu6XEfpdmAaJ5LWTk/B1FcM4xh1fwiOlammw0O4f0jsK+t/6DlrnRFxAUbnHcHcrPGAiNno/gpZPaehq/20Cxtg9p0hRaM5u0Em aK1DuTBv TC3GkmcIJUlTssl9k6Omwtand/OU3qjXyZ7F+7P66iigC1L6md7NbLxAiLMaTOiFHgZGx+pQCn7QqFBKoUQThke+Ou6kg9fJdrusAtruxHfDrK7+kM1eam3i+Qeu7h9qGWSL1MGQ12xlwEQjBEPrD5QPURbnp/cdfUD2QXdhWySfKZlSuopMU59T4oHtEzk/5DRwP X-Bogosity: Ham, tests=bogofilter, spamicity=0.000183, 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, 29 Feb 2024 04:10:03 PST (-0800), cyy@cyyself.name wrote: > This patch has not been reviewed for more than a month. There is another patch that did the same fix but in another way and still has not been reviewed like this. I'm here to do a comparison of some choices briefly to let the maintainer understand the issues and the solutions. I think it's time to make a decision before the next Linux LTS v6.9. As a number of sv48 chips will be released this year. > > Issues: > > Since commit add2cc6b6515 ("RISC-V: mm: Restrict address space for sv39,sv48,sv57") from patch [1], userspace software cannot create virtual address memory mapping on the hint address if the address larger than (1<<38) on sv48, sv57 capable CPU using mmap without MAP_FIXED set. > > This is because since that commit, the hint address is treated as the upper bound to create the mapping when the hint address is larger than (1<<38). > > Existing regression for userspace software since that commit: > - box64 [2] Is this the same regression as before? IIUC the real issue there is that userspace wasn't passing MAP_FIXED and expecting a fixed address to be mapped. That's just a bug in userspace. Is there any software that uses mmap() in a legal way that the flags patch caused a regression in? If that's the case then we'll need to figure out what it's doing so we can avoid the regression. The only thing I can think of are realloc-type schemes, where rounding the hint address down would result in performance problems. I don't know of anything like that specifically, but I think Charlie's patch would fix it. > Some choices are: > > 1. Do not change it > > Con: > > This behavior is not the same as x86, arm64, and powerpc when treating memory address space larger than 48-bit. On x86, arm64, and powerpc, if the hint address is larger than 48-bit, mmap will not limit the upper bound to use. > > Also, these ISAs limit the mmap to 48-bit by default. However, RISC-V currently uses sv39 by default, which is not the same as the document and commit message. IIUC arm64/amd64 started with 48-bit-capable hardware and kernels, and thus the only regression was when moving to the larger VA spaces. We started with sv39-based VA space, > 2. Use my patch > > which limits the upper bound of mmap to 47-bit by default, if the hint address is larger than (1<<47), then no limit. > > Pros: Let the behavior of mmap align with x86, arm64, powerpc > > Cons: A new regression for software that assumes mmap will not return an address larger than the hint address if the hint address is larger than (1<<38) as it has been documented on RISC-V since v6.6. However, there is no change in the widespread sv39 systems we use now. The OpenJDK and Go people have at least talked about using the interface as it is currently defined. I'm trying to chase down some of the folks around here who understand that stuff, but it might take a bit... > 3. Use Charlie's patch [3] > > which adjusts the upper bound to hint address + size. IMO we can call that compatible with the docs. There's sort of a grey area in "A hint address passed to mmap will cause the largest address space that fits entirely into the hint to be used" as to how that hint address is used, but I think interpreting it as the base address is sane and we can just update the docs. This also should fix the realloc-type cases I can think of, though those are sort of theoretical right now. > Pros: Still has upper-bound limit using hint address but allows userspace to create mapping on the hint address without MAP_FIXED set. > > Cons: That patch will introduce a new regression even for the sv39 system when creating mmap with the same hint address more than one time if the hint address is less than round-gap. I'm not quite sure what you're trying to say there. If users are passing a hint that's already allocated then they're not going to get that address allocated, so as long as we give them something else we're OK. We might want to take more advantage of the clause in the docs that allows larger addresses to be allocated under memory pressure to avoid too many allocation failures, but that applies to any of these schemes. > 4. Some new ideas currently are not on the mailing list > > Hope this issue can be fixed before the Linux v6.9 release. > > Thanks, > Yangyu Chen > > [1] https://lore.kernel.org/linux-riscv/20230809232218.849726-2-charlie@rivosinc.com/ > [2] https://github.com/ptitSeb/box64/commit/5b700cb6e6f397d2074c49659f7f9915f4a33c5f > [3] https://lore.kernel.org/linux-riscv/20240130-use_mmap_hint_address-v3-0-8a655cfa8bcb@rivosinc.com/