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 40A0AC35FFA for ; Wed, 19 Mar 2025 20:48:01 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id BD4AF280005; Wed, 19 Mar 2025 16:47:58 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id B606E280004; Wed, 19 Mar 2025 16:47:58 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 9D81B280005; Wed, 19 Mar 2025 16:47:58 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0016.hostedemail.com [216.40.44.16]) by kanga.kvack.org (Postfix) with ESMTP id 7C4F5280004 for ; Wed, 19 Mar 2025 16:47:58 -0400 (EDT) Received: from smtpin10.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id DD0C11A070F for ; Wed, 19 Mar 2025 20:47:59 +0000 (UTC) X-FDA: 83239487478.10.BBC9240 Received: from mail-ua1-f43.google.com (mail-ua1-f43.google.com [209.85.222.43]) by imf29.hostedemail.com (Postfix) with ESMTP id 0128A120006 for ; Wed, 19 Mar 2025 20:47:57 +0000 (UTC) Authentication-Results: imf29.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=MGbdQD6C; spf=pass (imf29.hostedemail.com: domain of 21cnbao@gmail.com designates 209.85.222.43 as permitted sender) smtp.mailfrom=21cnbao@gmail.com; dmarc=pass (policy=none) header.from=gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1742417278; 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:references:dkim-signature; bh=KKbC0MuH8cvSdNHe6VOBpxzuJRseZmE5AVgpdhwM68I=; b=iXA8KFUuUc+zwtO1Jqjge0Vogk39NxsqBlNO1IE8RvtBpyyZ4bPfL6AtPkfP3zEdVAmkSc VIiDlHvO9Aok+TaDTWUYXnfAyfRdZSwj0LZFaZABUNMyv6L2+H3Z7PQp/xkl9dIrclaEIX w1cUmJtE9evRA3wrlL4kwSOHJcXyGUM= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1742417278; a=rsa-sha256; cv=none; b=xqh2a+NE81O7aMOJKrD1GtiUyvcTZkZS8Dld6JfF3yHNl3P7btxms+vtHYrpYMgcKVsRp1 btSHv8hVRAUv2UBgXfca4bDTuHcLiC0WoMLP/hB4EZ+YTZAxh7QNBrCvBiND1+9NjDQX53 rgVjr1o9BnVTmHKhdBPxGD/Hp4QRVEY= ARC-Authentication-Results: i=1; imf29.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=MGbdQD6C; spf=pass (imf29.hostedemail.com: domain of 21cnbao@gmail.com designates 209.85.222.43 as permitted sender) smtp.mailfrom=21cnbao@gmail.com; dmarc=pass (policy=none) header.from=gmail.com Received: by mail-ua1-f43.google.com with SMTP id a1e0cc1a2514c-8670fd79990so15951241.3 for ; Wed, 19 Mar 2025 13:47:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1742417277; x=1743022077; darn=kvack.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=KKbC0MuH8cvSdNHe6VOBpxzuJRseZmE5AVgpdhwM68I=; b=MGbdQD6C1nk5T+JPe8rUMPTL+f3ItsyN4BrgvKZmBK8OKV0bZjhoNJJGjbEgJBIYO+ vGh52iEDh2KFcN4B2QLyOsp/oe9nWaUhRhKZ/R6zDBINvQTio4MNkaVhwbswy1aX4OSz X7TJ9Xqq6rlF4MqaZWgRL/VY9LPzpXu0PkOAxm9uw+t+CUle3zms4K6DaaQ7pJ/6JfWH e1PP6o8Qiqrc0m9SlqeCfHoY/e8e4ljd+WVU/CD+oPUUf7jSPLy+VTS2Z+wfMPw33COr JXZyM6APbxlOyzU2EdI1oUHBcPFhsT9kcAyyTY3442WsQhMT1szz8Q4zQoD1lnIHpcxh HXoA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1742417277; x=1743022077; h=content-transfer-encoding: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=KKbC0MuH8cvSdNHe6VOBpxzuJRseZmE5AVgpdhwM68I=; b=jPWGmHkr32U4wy3Pzb4Lpkat45QFsgav45msIbzawFxxUiLMvq1HnemLwSJvoAvtiB diznSUQ7oJtFTQzGZPL9JPSjSgZYVkvH0ywoYF9TzvkZKWycbar28+OaDSkJmgSoeO78 k9Yrde7kJhkSQIW+8JmF72NXzy6JVM/WYbEdTKnL+ST5kTiAeTOUiMZ0cVLkWcJjQJrD 6R/+9nzig2lh0F86DrNo8zfrjNEqJdvKT+Qg2PSfyj5XBF1N6EyEH6cNzI3JMcIkN+HA K/4+WjnoiRnbTZfBUCVv0p/5Tn0PBmi+GJqdV39l/CPmGZFNgW91e3Gh9wJJwtrB0Te2 2zIg== X-Forwarded-Encrypted: i=1; AJvYcCXijm+tm6NgNkseD/tQoFk5m+pB6giQndbwD39bTerYNiISIkZmMoLsrZ0lBJq2h+f6hstF9LqKeQ==@kvack.org X-Gm-Message-State: AOJu0YwNwQaRsRmOX1iU+xoeXFUBj+15oHOYmtXmnYcJgnh5tcavyQ2+ ct0VV1lpSI9WLeG9R7iGLaO4I7ugQl5/Gj93qDaoQ5U1eSZ+95Y8ny04gmF+mcnST62qoudUh8v /Lo2oZ2I8HiSloW+efU8Y8yxsz0k= X-Gm-Gg: ASbGncty81nB7dRJBhrXfVCjmv/5GacNmlFLd1bQjJpCsYX+XB5FwWJgBEZLlHo2MSt AENS+ZUTUaFRtN36doHEqDhO5fIld8PCYG+P1oc+z9iR6Q2pjhlLVAWZAH1wuDjiAk8uVl7lJCv HS9MMNDStG/AwPD+t3Oq6i9OsT5EM0i2ChGHaX X-Google-Smtp-Source: AGHT+IFc/S9+QOK97bxXvbfOsz6wh+mWa+ZN4T48JugJD3KXENYS5nxfAFKlVJIIvvPVbTOK+bCuUoD4SBVIcSSashw= X-Received: by 2002:a05:6102:5718:b0:4c4:e21f:646b with SMTP id ada2fe7eead31-4c4ec625cc7mr3752052137.5.1742417277000; Wed, 19 Mar 2025 13:47:57 -0700 (PDT) MIME-Version: 1.0 References: <6201267f-6d3a-4942-9a61-371bd41d633d@arm.com> In-Reply-To: <6201267f-6d3a-4942-9a61-371bd41d633d@arm.com> From: Barry Song <21cnbao@gmail.com> Date: Thu, 20 Mar 2025 09:47:46 +1300 X-Gm-Features: AQ5f1JqTHkBlaFTMHJfoynJwh2kYOo8uzfxcoSxORhzFo55ke1PQv_2loIbeHBg Message-ID: Subject: Re: [LSF/MM/BPF TOPIC] Mapping text with large folios To: Ryan Roberts Cc: lsf-pc@lists.linux-foundation.org, Linux-MM , Matthew Wilcox , Dave Chinner Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspam-User: X-Rspamd-Server: rspam01 X-Rspamd-Queue-Id: 0128A120006 X-Stat-Signature: yt39if4e1o441pw99nem9tjmew54gdyh X-HE-Tag: 1742417277-381649 X-HE-Meta: U2FsdGVkX19+LhKCaZb8aizEHuo8ZWg660U9w8gG0wiPNrgpOr9N7VlCE0K8K/MbaZLk00zGxV60trQoA1Ga6BSAE8I6Qg6uGmlexqWnBaXvy5zQjEqNznKyj34+qgx4N14NducvSfwPMA7xN2LRis2NHHSDlsPH5JDNARioRw9ke23gqsosAm84KW4bEHyMLQ0na3pN0LNqXDpZQgku+q0gxTUvUOQTlKWniTprgpgoCv/rICdpIunKzuZtsLc6xh/4FvbX0Rd9WzaarRe0RbnM3qG49rdjS+a+JTS6+U2cYeLLIgVXfXGZn43AWAUYfZwONhfvl019TKlSE2ebT7nlMg0iwNR3LNT4vWKHOkZoCkcdFpKKQm/ZqMzFGGF4l/+Ix2bvlYFRsq9i4BIzlbrE4HOKErWj/0J5zD/VV3xSxPDGo6gXPxqSnY485tqnhu8LCNFAMMXlF4UcFF64hWhN2R+VVqxIjZP5tNpRsUV9gBTBCgoNu7zOQpCHbyE2PH90DyedpskxRkcMc9OUhrn/Dp3+MO7Uhlm7MkVmrSNQcwRXPn09yqx1f3Y3+1P2NNIaqsa51ozSxrYG1XG3mtLMTdYMNV73jW22n55CZSH0OvfhfqjwLDLHC4Zmz2cwkC2rppj69WinIEyEwDkoUJ3JmRs9KhdwnpBoyf9j37AEZputfm6TvCd+0YGCVq+zkyR0guPOk+JnbrrO7g6hO1JOt2fG4fbQIO5lPWy8jsudZbCOlrofInrqox5AED6ITiLnJc8TBXHM8xuT3/I6waGibmf9AAPOZ53keqTG7dszDeCZ3pP9TQJjIvKjiYragsxi80G7yXOwpKlIVKZEgNCc300301JhaMWG4Q+LErh/86ZC0/SpMhqaTaldtC+YsAMfllOwyi4A/9b1t9KbwGgrKYkkSJK2MLbKQkVjyxO8i2Ne+wYmQexzsa4bXXcx1akNtru03sFPihWcsnK 2k3/+zuC PztcDJ7B25Phe+iQ/ZGi0tunJ1VRoz9JJ2MJoDBPhqciSZuh1UEWjqBhYMQ4Oz3SF52MPcOvuI2U9sBRXPtl1+F1o0jdrBoBTyOR3RbsHAUTddT1Sly2iUVdxFofxjOTWnPt8q+vivM9IHjS4OkZ5Tzq12tKTsbOf4vQ5KCnDIVZY8tQ2dup2wb4oYUb5Ewk7Hcd3ZNZQyCBykoK3DSq6Ne6j1SfKblpmEhISOtkVBnmEh5/2yiQiWeyyMVMVWqyjEkfjzHqcJwsny0GDtouxUsdfmB5Al+Btv9RyYJt0ggxENWeJw8tpNrRWDVLhi3sniheIVaslSqc4PA440uSXqAiADVLE2XOOASsjDNCVdz0gVkOtrQW4cc/RVL5GSI0xcwAt/LvF40AU22X9zVSivtjD+g== 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 Thu, Mar 20, 2025 at 4:38=E2=80=AFAM Ryan Roberts = wrote: > > Hi All, > > I know this is very last minute, but I was hoping that it might be possib= le to > squeeze in a session to discuss the following? > > Summary/Background: > > On arm64, physically contiguous and naturally aligned regions can take ad= vantage > of contpte mappings (e.g. 64 KB) to reduce iTLB pressure. However, for fi= le > regions containing text, current readahead behaviour often yields small, > misaligned folios, preventing this optimization. This proposal introduces= a > special-case path for executable mappings, performing synchronous reads o= f an > architecture-chosen size into large folios (64 KB on arm64). Early perfor= mance > tests on real-world workloads (e.g. nginx, redis, kernel compilation) sho= w ~2-9% > gains. > > I=E2=80=99ve previously posted attempts to enable this performance improv= ement ([1], > [2]), but there were objections and conversation fizzled out. Now that I = have > more compelling performance data, I=E2=80=99m hoping there is now stronge= r > justification, and we can find a path forwards. > > What I=E2=80=99d Like to Cover: > > - Describe how text memory should ideally be mapped and why it benefits > performance. > > - Brief review of performance data. > > - Discuss options for the best way to encourage text into large folios: > - Let the architecture request a preferred size > - Extend VMA attributes to include preferred THP size hint We might need this for a couple of other cases. 1. The native heap=E2=80=94for example, a native heap like jemalloc=E2=80= =94can configure the base "granularity" and then use MADV_DONTNEED/FREE at that granularity to manage memory. Currently, the default granularity is PAGE_SIZE, which ca= n lead to excessive folio splitting. For instance, if we set jemalloc's granularity to 16KB while sysfs supports 16KB, 32KB, 64KB, etc., splitting can still occur= . Therefore, in some cases, I believe the kernel should be aware of how userspace is managing memory. 2. Java heap GC compaction - userfaultfd_move() things. I am considering adding support for batched PTE/folios moves in userfaultfd_move(). If sysfs enables 16KB, 32KB, 64KB, 128KB, etc., but the userspace Java heap moves memory at a 16KB granularity, it could lead to excessive folio splitting. For exec, it seems we need a userspace-transparent approach. Asking each application to modify its code to madvise the kernel on its preferred exec = folio size seems cumbersome. I mean, we could whitelist all execs by default unless an application expli= citly requests to disable it? > - Provide a sysfs knob > - Plug into the =E2=80=9Cmapping min folio order=E2=80=9D infrastruc= ture > - Other approaches? > > [1] https://lore.kernel.org/all/20240215154059.2863126-1-ryan.roberts@arm= .com/ > [2] https://lore.kernel.org/all/20240717071257.4141363-1-ryan.roberts@arm= .com/ > > Thanks, > Ryan Thanks Barry