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 3DBAAC54E71 for ; Fri, 22 Mar 2024 14:14:26 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 944EA6B008C; Fri, 22 Mar 2024 10:14:25 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 8F4E56B0095; Fri, 22 Mar 2024 10:14:25 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 7E2E46B0096; Fri, 22 Mar 2024 10:14:25 -0400 (EDT) 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 70EA86B008C for ; Fri, 22 Mar 2024 10:14:25 -0400 (EDT) Received: from smtpin21.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id 34A941612F2 for ; Fri, 22 Mar 2024 14:14:25 +0000 (UTC) X-FDA: 81924870090.21.60B62D4 Received: from mail-yw1-f173.google.com (mail-yw1-f173.google.com [209.85.128.173]) by imf23.hostedemail.com (Postfix) with ESMTP id 5EC63140002 for ; Fri, 22 Mar 2024 14:14:23 +0000 (UTC) Authentication-Results: imf23.hostedemail.com; dkim=pass header.d=dabbelt-com.20230601.gappssmtp.com header.s=20230601 header.b=01LW1I9F; spf=pass (imf23.hostedemail.com: domain of palmer@dabbelt.com designates 209.85.128.173 as permitted sender) smtp.mailfrom=palmer@dabbelt.com; dmarc=none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1711116863; 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=yMwbsV2lr5D+n8eq4lwX8uN+1JbL7Okl9fmvTySMdOM=; b=LygSfvMSlNDS5wLjrKVdotIpjhtqunxTGqklBs2mdhaHW2r8PoY1RjKB/guwIops1r6qbf xcR2ZCjQwUZmDZBXhtkGLwt+iGEq4Mt9w3CIGiDUJauNf0o5GeQDBIb9P51PowUAhc+Nr3 GWYt2N/K+o0ZlfjSGisWH6tU8FGojfw= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1711116863; a=rsa-sha256; cv=none; b=HKBWiwp66PR7hGthBCQ8fCGejOUp0Wooul/j6vg1IDEx5ALILY8FxJZ0ghNZJEefeozEPB jdkUC14hOwHj2mcOG2ty3GDHKrPe9Hcw6QixCrNbNc7T+pTcS1bPgDl2EdXnRI7ZyiL3hw cPzqLNTxjrsUjbHHu7rSEXIwLsfGdlc= ARC-Authentication-Results: i=1; imf23.hostedemail.com; dkim=pass header.d=dabbelt-com.20230601.gappssmtp.com header.s=20230601 header.b=01LW1I9F; spf=pass (imf23.hostedemail.com: domain of palmer@dabbelt.com designates 209.85.128.173 as permitted sender) smtp.mailfrom=palmer@dabbelt.com; dmarc=none Received: by mail-yw1-f173.google.com with SMTP id 00721157ae682-60a0a1bd04eso23395017b3.1 for ; Fri, 22 Mar 2024 07:14:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dabbelt-com.20230601.gappssmtp.com; s=20230601; t=1711116862; x=1711721662; 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=yMwbsV2lr5D+n8eq4lwX8uN+1JbL7Okl9fmvTySMdOM=; b=01LW1I9F7f33z//65l/x6b/LL6rVIk13bs115xQVdME6EUhtskLzJFPKNV9BROL0ht 79r5rCBssJgtSRvahGuVEeVtCZ2sOoVV+IVIYs7HH6z7S6Fyzn9Y03vAFmO9vL9Wfyiz 4YxLCoc7biGikyxag9s/eRKjGnISiKw7yWNG5jRhvNzQvtvqDyurj6UcKEwerBiZrR8p +I3/kdjo82VSu4yk2SilupaI1yxrmTBioeGq8+kCSy3vJklemyAaYbxDJBgL6wF/SDue f4IzzLFAvp2uDPM1UCcw60LITXmqoV9jJPyl04mkWjpPxdNUVAXl4MeRry9lJXD4q2E3 rT/g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1711116862; x=1711721662; 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=yMwbsV2lr5D+n8eq4lwX8uN+1JbL7Okl9fmvTySMdOM=; b=SBlpY+EpPxka4+85PS2D9IFm2C4gXrgFlfu12pTi4QQhhh889O4e5lLB/RLDx9nuB7 GGrnVul/GMQSSMNSVuXzOYNwkpBOuvE0DGfz5BIdQ5L6LpIZM2GEOL7tl1T63S2sd3cu U+ouOg1OE1yM2P9U0ZANxhFZCY2ctJOuWLEbvHeQHVIdK8WMpHXtr62ArC0/0FRnrqF9 iza0bqi/Edsj/5MZ+P4SXU7dhdoF/rijNkP86Bxm24672GOXFDn42GR5C261cGOXyj6w poofHP45F9dQKpRk60JEcgBbiTvS3Q4z3VXCdwcBMw1sCkAqYkjfy0fuKuFeP/uaWpEl y6OA== X-Forwarded-Encrypted: i=1; AJvYcCWF5VyhpgOs9B9IuNv6S61QeB4eNC/6+SxG35UW7/ql1Iebmj0+7Z+i8rDe9kFXptfYkfX5jC0W5Bbltew70PgU2GQ= X-Gm-Message-State: AOJu0YxPENJMmbZjHH78uxhJsX7o2MF7f5ZHHK7uTtrCzpVnQ13Ca3Mm cFDcCJO6Y8whfiaIA7SFbHhFg75oUYWQesDnw7iwsULSktwNnaP+HNxKaL56vTfge0+Dm2eQUMY n X-Google-Smtp-Source: AGHT+IF67p/WhASEEUOaMLQ7DminN+c4zr/4NoTc7CLi/rZc+sVKHX93JtQeh2Zc4uFIFtVUaKoXtg== X-Received: by 2002:a05:6a21:920a:b0:1a3:7b9a:4dd6 with SMTP id tl10-20020a056a21920a00b001a37b9a4dd6mr2763771pzb.54.1711116379234; Fri, 22 Mar 2024 07:06:19 -0700 (PDT) Received: from localhost ([192.184.165.199]) by smtp.gmail.com with ESMTPSA id x8-20020a056a000bc800b006ea918dab9csm94982pfu.157.2024.03.22.07.06.18 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 22 Mar 2024 07:06:18 -0700 (PDT) Date: Fri, 22 Mar 2024 07:06:18 -0700 (PDT) X-Google-Original-Date: Fri, 22 Mar 2024 07:06:16 PDT (-0700) Subject: Re: [PATCH v3 1/3] riscv: mm: Use hint address in mmap if available In-Reply-To: CC: cyy@cyyself.name, alexghiti@rivosinc.com, Paul Walmsley , aou@eecs.berkeley.edu, shuah@kernel.org, corbet@lwn.net, linux-mm@kvack.org, linux-riscv@lists.infradead.org, linux-kernel@vger.kernel.org, linux-kselftest@vger.kernel.org, linux-doc@vger.kernel.org From: Palmer Dabbelt To: Charlie Jenkins Message-ID: Mime-Version: 1.0 (MHng) Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Rspamd-Queue-Id: 5EC63140002 X-Rspam-User: X-Rspamd-Server: rspam11 X-Stat-Signature: dbwzb9qb5g9apez13hcxt7wg43izyjs3 X-HE-Tag: 1711116863-95284 X-HE-Meta: U2FsdGVkX1+wQXGYWnVJAr7quwMO42jq4JIP2JA4yIY0UnIS4iImyZ36yL4ZFUXasTKS8zBswcGpv9OBkIpK3gGMRwvph4vdysutPmDUUEQtsqmOLk5rxzBWkxrLgEsqugV4hp8xzVmV2oISUQDczOt8LI697lN92vnzW3Eim+HGB1TV4lN4QsNRES0w+d+17ZFPB8aHF5+3XDwlMSq+8OYprSf6dLTqGNIHkOLDyl4DBnXrod79B/1fL/AMQqb4Yejn5+I0PEhggd4DKjFRGNTKt3rDwv9xY+tWUyvAGf+pxAETkk0lpgnEg65vatNc6euPksI++/SSbA80mb79QUKo160T6VmZDuHUFEUq5Ls/fxBYk0mcjkJz4fcsKQo9rZweMgKYBwlKDMefPWik3gNrSOInapT5+iwX36TSnX8wBt5yi/eB1iiBQ+mZlWN8j+NlMNDamLcHir7yZBDgKAniSc8rHxDsWKevAALfhbML1yqkQwgPshDeAlPMKl8H+dd6AcnXeay7MBy5fnRwobIsd1zjrxbEF9z42+Yux2ktPzd05v+Ag6J4sDfQiKA0iqXds6wynDj9ddtweSNF49tlI3N0LK4Cj5TkvGzVdC82fVv62c4Sc3PCEbRS3Z1wn8d42ysk5vGUW/mnSaKFlhf3DJ1v1HOJ/RbEDuADLOhqtnhN8W6QGp4u4kQoO0GpBnNfJOqAWg2x0Jm/BUdfMr7ZKJh9R0LlOmPiOGybVKHTFa1Bc8pDPFSypuB1GV3uEn2ql+72n6wYyPMTLYvHRzMWDglix+r2ykf4ca/uN6Ku6hEaIk6qyLoff52x1KBGu7PbqcxNCpFkkKRR2UDMHsWHoJlbAM4x2Zmm7qwVrCSi+RJJqShASaICGdX+b90dKHLhsUJDrlVfMckdVIIMwdM9YJuRG4f2tQj5MHwGVBz+Jn+L+LkeuSajglhoASjZ6HiXAwcPKDteGoVYKOH UXFh6lRT 5TKCVhhY6pF+Rpiv68JT9g5WagaHvi+RQjTGvBDIflCbixTUvfex25jwbH+la8WYIv/pijIM4qNXxkxrk2Vt7SKtf7/ygBBS9p+wiZbcUUJ2dmTMrbentoCzMwL2CfMXos7mOLc8fKJYBBUB50a1QoOu+gA== X-Bogosity: Ham, tests=bogofilter, spamicity=0.000004, 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, 01 Feb 2024 18:28:06 PST (-0800), Charlie Jenkins wrote: > On Wed, Jan 31, 2024 at 11:59:43PM +0800, Yangyu Chen wrote: >> On Wed, 2024-01-31 at 22:41 +0800, Yangyu Chen wrote: >> > On Tue, 2024-01-30 at 17:07 -0800, Charlie Jenkins wrote: >> > > On riscv it is guaranteed that the address returned by mmap is less >> > > than >> > > the hint address. Allow mmap to return an address all the way up to >> > > addr, if provided, rather than just up to the lower address space. >> > > >> > > This provides a performance benefit as well, allowing mmap to exit >> > > after >> > > checking that the address is in range rather than searching for a >> > > valid >> > > address. >> > > >> > > It is possible to provide an address that uses at most the same >> > > number >> > > of bits, however it is significantly more computationally expensive >> > > to >> > > provide that number rather than setting the max to be the hint >> > > address. >> > > There is the instruction clz/clzw in Zbb that returns the highest >> > > set >> > > bit >> > > which could be used to performantly implement this, but it would >> > > still >> > > be slower than the current implementation. At worst case, half of >> > > the >> > > address would not be able to be allocated when a hint address is >> > > provided. >> > > >> > > Signed-off-by: Charlie Jenkins >> > > --- >> > >  arch/riscv/include/asm/processor.h | 27 +++++++++++--------------- >> > > - >> > >  1 file changed, 11 insertions(+), 16 deletions(-) >> > > >> > > diff --git a/arch/riscv/include/asm/processor.h >> > > b/arch/riscv/include/asm/processor.h >> > > index f19f861cda54..8ece7a8f0e18 100644 >> > > --- a/arch/riscv/include/asm/processor.h >> > > +++ b/arch/riscv/include/asm/processor.h >> > > @@ -14,22 +14,16 @@ >> > >   >> > >  #include >> > >   >> > > -#ifdef CONFIG_64BIT >> > > -#define DEFAULT_MAP_WINDOW (UL(1) << (MMAP_VA_BITS - 1)) >> > > -#define STACK_TOP_MAX TASK_SIZE_64 >> > > - >> > >  #define arch_get_mmap_end(addr, len, flags) \ >> > >  ({ \ >> > >   unsigned long >> > > mmap_end; \ >> > >   typeof(addr) _addr = (addr); \ >> > > - if ((_addr) == 0 || (IS_ENABLED(CONFIG_COMPAT) && >> > > is_compat_task())) \ >> > > + if ((_addr) == 0 || \ >> > > +     (IS_ENABLED(CONFIG_COMPAT) && is_compat_task()) || \ >> > > +     ((_addr + len) > BIT(VA_BITS - >> > > 1))) \ >> > >   mmap_end = STACK_TOP_MAX; \ >> > > - else if ((_addr) >= VA_USER_SV57) \ >> > > - mmap_end = STACK_TOP_MAX; \ >> > > - else if ((((_addr) >= VA_USER_SV48)) && (VA_BITS >= >> > > VA_BITS_SV48)) \ >> > > - mmap_end = VA_USER_SV48; \ >> > >   else \ >> > > - mmap_end = VA_USER_SV39; \ >> > > + mmap_end = (_addr + len); \ >> > >   mmap_end; \ >> > >  }) >> > >   >> > > @@ -39,17 +33,18 @@ >> > >   typeof(addr) _addr = (addr); \ >> > >   typeof(base) _base = (base); \ >> > >   unsigned long rnd_gap = DEFAULT_MAP_WINDOW - (_base); \ >> > > - if ((_addr) == 0 || (IS_ENABLED(CONFIG_COMPAT) && >> > > is_compat_task())) \ >> > > + if ((_addr) == 0 || \ >> > > +     (IS_ENABLED(CONFIG_COMPAT) && is_compat_task()) || \ >> > > +     ((_addr + len) > BIT(VA_BITS - >> > > 1))) \ >> > >   mmap_base = (_base); \ >> > > - else if (((_addr) >= VA_USER_SV57) && (VA_BITS >= >> > > VA_BITS_SV57)) \ >> > > - mmap_base = VA_USER_SV57 - rnd_gap; \ >> > > - else if ((((_addr) >= VA_USER_SV48)) && (VA_BITS >= >> > > VA_BITS_SV48)) \ >> > > - mmap_base = VA_USER_SV48 - rnd_gap; \ >> > >   else \ >> > > - mmap_base = VA_USER_SV39 - rnd_gap; \ >> > > + mmap_base = (_addr + len) - rnd_gap; \ >> > >   mmap_base; \ >> > >  }) >> > >   >> > > +#ifdef CONFIG_64BIT >> > > +#define DEFAULT_MAP_WINDOW (UL(1) << (MMAP_VA_BITS - 1)) >> > > +#define STACK_TOP_MAX TASK_SIZE_64 >> > >  #else >> > >  #define DEFAULT_MAP_WINDOW TASK_SIZE >> > >  #define STACK_TOP_MAX TASK_SIZE >> > > >> > >> > I have carefully tested your patch on qemu with sv57. A bug that >> > needs >> > to be solved is that mmap with the same hint address without >> > MAP_FIXED >> > set will fail the second time. >> > >> > Userspace code to reproduce the bug: >> > >> > #include >> > #include >> > #include >> > >> > void test(char *addr) { >> >     char *res = mmap(addr, 4096, PROT_READ | PROT_WRITE, >> > MAP_ANONYMOUS >> > > MAP_PRIVATE, -1, 0); >> >     printf("hint %p got %p.\n", addr, res); >> > } >> > >> > int main (void) { >> >     test(1<<30); >> >     test(1<<30); >> >     test(1<<30); >> >     return 0; >> > } >> > >> > output: >> > >> > hint 0x40000000 got 0x40000000. >> > hint 0x40000000 got 0xffffffffffffffff. >> > hint 0x40000000 got 0xffffffffffffffff. >> > >> > output on x86: >> > >> > hint 0x40000000 got 0x40000000. >> > hint 0x40000000 got 0x7f9171363000. >> > hint 0x40000000 got 0x7f9171362000. >> > >> > It may need to implement a special arch_get_unmapped_area and >> > arch_get_unmapped_area_topdown function. >> > >> >> This is because hint address < rnd_gap. I have tried to let mmap_base = >> min((_addr + len), (base) + TASK_SIZE - DEFAULT_MAP_WINDOW). However it >> does not work for bottom-up while ulimit -s is unlimited. You said this >> behavior is expected from patch v2 review. However it brings a new >> regression even on sv39 systems. >> >> I still don't know the reason why use addr+len as the upper-bound. I >> think solution like x86/arm64/powerpc provide two address space switch >> based on whether hint address above the default map window is enough. >> > > Yep this is expected. It is up to the maintainers to decide. Sorry I forgot to reply to this, I had a buffer sitting around somewhere but I must have lost it. I think Charlie's approach is the right way to go. Putting my userspace hat on, I'd much rather have my allocations fail rather than silently ignore the hint when there's memory pressure. If there's some real use case that needs these low hints to be silently ignored under VA pressure then we can try and figure something out that makes those applications work. > > - Charlie