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 9B3A7C48BF8 for ; Thu, 22 Feb 2024 20:36:55 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 2EF516B006E; Thu, 22 Feb 2024 15:36:55 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 278956B0071; Thu, 22 Feb 2024 15:36:55 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 119376B0072; Thu, 22 Feb 2024 15:36:55 -0500 (EST) 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 EBB2B6B006E for ; Thu, 22 Feb 2024 15:36:54 -0500 (EST) Received: from smtpin27.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id A2D64A07F7 for ; Thu, 22 Feb 2024 20:36:54 +0000 (UTC) X-FDA: 81820598748.27.A849F60 Received: from mail-vs1-f43.google.com (mail-vs1-f43.google.com [209.85.217.43]) by imf26.hostedemail.com (Postfix) with ESMTP id 05E96140013 for ; Thu, 22 Feb 2024 20:36:52 +0000 (UTC) Authentication-Results: imf26.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=F4FzOz+d; spf=pass (imf26.hostedemail.com: domain of fvdl@google.com designates 209.85.217.43 as permitted sender) smtp.mailfrom=fvdl@google.com; dmarc=pass (policy=reject) header.from=google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1708634213; a=rsa-sha256; cv=none; b=2A2B9gJrGPWA41GGBYDEaAs0/ehlrkXARd2OLrayaLeQAxX6EeEv9TAyr4feYZlVYQ6EUx b9TPrG1p61NaEq1/MvLJPOYWy78dzKRUnImFpZzZGGreaOtF5hzxZbFpXGG7gj0r3rPCYd cZWhJCxZLuTFkbkVuB95z33sM1/G/QE= ARC-Authentication-Results: i=1; imf26.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=F4FzOz+d; spf=pass (imf26.hostedemail.com: domain of fvdl@google.com designates 209.85.217.43 as permitted sender) smtp.mailfrom=fvdl@google.com; dmarc=pass (policy=reject) header.from=google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1708634213; 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=ykFkSRAZnk0PAxUf2AKWTawWOr30NIdA96N0CblhPtE=; b=RO32hhwERkNmLynuyu8rgqdY40oS0CKcuhjuZnN8OB0UXJ/SYshb7A2rsCZG/nHa/CxfdJ 9tTzDTmgltBFStFcCWMv4+81ikZF1HM2hq461GrrCbMsptxMCZUpInoTTkU4srHpSGWL3l mea69iSsfpzkx6kmT8mQ+p5yRavyxNk= Received: by mail-vs1-f43.google.com with SMTP id ada2fe7eead31-471c3d23d28so257386137.0 for ; Thu, 22 Feb 2024 12:36:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1708634212; x=1709239012; 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=ykFkSRAZnk0PAxUf2AKWTawWOr30NIdA96N0CblhPtE=; b=F4FzOz+d+A4TLM/EyYJXJt1SrUb+yi66g/dlAW7uvE9SLaJRJkrCOmztZ8DOjY79mC lnPswJM0RFybMjXDqIxkvRMpLvVTsW+9MNlWx9ssyZDAXC7cAxalrwtjvefLniPXpZoa SoJqbqxsIDJMPV1DdLSkkeY/srHdTZTa0fqSrN3rVRaLW/KogeB7l7T32BRf7DLiToH1 9cD5yHQdYmSCUe+j1ylYhTvi6rhtbav8mYlLGpPD3tdM9dmMqy9s943Z3ode7AwxjZ4x vR6+NixbyYWRtV/Y/5+DGGha4V0x7hUpZKOgLlzrjX1Y1+tZfPjKDj/fgm1v5u7oiPuQ qwFw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1708634212; x=1709239012; 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=ykFkSRAZnk0PAxUf2AKWTawWOr30NIdA96N0CblhPtE=; b=L/4ZgdVqg1M+5MGAJnp9n2DcOkekwkPsibXy1iKLStXBosYHxMxnJMzPKQXfnv0Ne5 NyhDVuykzSBkYHsnpnujtZdlWrA6N9Z8slgsV/bESt1/w5bni6Zepfz0lhVgPfXHW7j8 bue1D+HU/reiVuQOkN9oylz9hKdUXv9c1zyhyzgRQGjmbVvbVJshaYmYQv92awVC1RZm pRQlCCjJavb/55F9/VSLV26X8RjHQbiHO6xTrbEQi9bz2JP9yM6DXK9xICqdGQAPFQia kCeT/HY/SAY6ScfMPeVzVJ71luadhO0AWSDAS0V0a1lbOVoBmLhIUM9Cxps2Ek4Prkx2 22sQ== X-Forwarded-Encrypted: i=1; AJvYcCX6gGjgkBafIxc0Ws8d8RGyXCmvc0IVHs1PcPbnq6T4+uoIxHQLOziQ6cIe9v8U1qDi1GHVOBb3z6L3SL2btNxVWcA= X-Gm-Message-State: AOJu0YxxCRGUsicuHk0no7G2sctrdetYFr+TIvN/9ksloCV9VbHG7RkB aaOpHroacJW+jecp6HsW0GvsA5gKHAmQLkmH59pUgUREaM7RZYXtm8zrWSc5uZqQzDkvmSa3esb KThirK3z0oJZWK4jQOI1lRbNtfU5rDft6dmEY X-Google-Smtp-Source: AGHT+IFGdx3GK8mO2U90UcZYIaM6nFvRmTSqdWd6WYnf/JbmjjOB7Nelv+PXKuVADsZWWamjJ/peuD3uIIePvI/C96U= X-Received: by 2002:a67:f71a:0:b0:46e:e826:941e with SMTP id m26-20020a67f71a000000b0046ee826941emr3376286vso.9.1708634211863; Thu, 22 Feb 2024 12:36:51 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Frank van der Linden Date: Thu, 22 Feb 2024 12:36:40 -0800 Message-ID: Subject: Re: [LSF/MM/BPF TOPIC] Hugetlb Unifications To: Peter Xu Cc: lsf-pc@lists.linux-foundation.org, linux-mm@kvack.org, James Houghton , Muchun Song Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Server: rspam08 X-Rspamd-Queue-Id: 05E96140013 X-Stat-Signature: a948x8b3hini8kfkjukyewicsxwdhene X-Rspam-User: X-HE-Tag: 1708634212-149060 X-HE-Meta: U2FsdGVkX1+X71hSvIwAsbbO4cd4HovMdQKGxeEHmSlG4Vn3JNeH8bDtAQ7PoHKCW2ucEOcI3pHjtCzTt+SVKNjCs8YEtitxsynYqKDEoDS/pCaj/AGZ0e1bfI+oz5Kra4kcSwK+3cLqUAuZ6+QLkNSKRpukKw5jyg0idrTKmtz5SplE8empyeU4Qd05uDtMY5q4CUxi2ONj3ujsLl+CqcG77KmLJlq9spa9qoyQCG942qgo2fCcJcOyhLFdIllJ1siocipojsVpCgL+7ZqCIUTUh4p+r/ihjy5jpJDDME72Cp6ciNM3dwZ5l1FKtm0t52Bdv1vwFI6ht238cl7okM6J0vn9zw5BfSpW+tg8Wgjx7Id0eXGoJrBGHCAbdvJ7Hq1gr+/WfmSVwsfBlQscsub1IQ5TZRNyoL4gqzL4whQbbXPxIWG7y2DUOKrsKQ0tbtLmpll/zTgGBEdCqY82Ah77BQjeBnvyr9I2Pmr3tWkxeGAqYqAQjG+Hg31SNH4qsnRmuZ3MW6FOFGCscHRYArFW03huiBMqlusrNivKhvtMx4Ff0cs+zp2mc62gWk/imqtj3wy9wyebn5rE0R8P6a20yjg+hN3+Cy6fNAZ2FRTSZh/WpjM02fAlZstpLrWZSUEBFBbXNeOj77ID2R51es+bbmPHlMCfJqDsyUoMFYh0zEvMQgJhh3Um2FLUsSuP5I4lpPzVVCj+RLun0dIy6pgsM0wvhQamPTjwlFzxzHz+2ZiV/ZrzM7dGNxzcgMOcCVoSdRgT9UiY1eAh5iG0txFyAPZ6J1IRsl7qWF0GwloQbna+24OuSdvIp0muLH3JQO6/wXiOgUYY36swRSxBpXd+PIsn5xzi4S+qAdU2EdtyYu1hXJdGIjJdsz4BRngc47uGv1+i1V4/HWPgHKwaEm1qM2NEv6fsCjA8pNScCJCQ1jkwrZ9wVGmyb9Ko7mChquJTuB1ZCj5fGSt5XUe fig== X-Bogosity: Ham, tests=bogofilter, spamicity=0.000001, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: +1 on this topic, thanks for bringing it up. This needs to be resolved, or it'll keep hanging over any future hugetlb feature changes. To me, it makes sense to have hugetlb pages themselves to just be large folios as much as possible. On top of that, there could be a notion of physical memory pools with certain properties. The properties can be things like: size, evictability, migratability, possibly persistence across reboots, maybe "should not be in the direct map", like memfd_secret. hugetlbfs then could be expressed as a filesystem on top of a pool of, for example, 1G non-evictable pages. The pools themselves could have a memfd-like interface (or use memfd itself), and could also be used to hook in to things like KVM guestmemfd. So yes, that would be a hugetlb v2, but mainly as a backward compatible layer on top of something more generic. - Frank On Thu, Feb 22, 2024 at 12:50=E2=80=AFAM Peter Xu wrote= : > > I want to propose a session to discuss how we should unify hugetlb into > core mm. > > Due to legacy reasons, hugetlb has plenty of its own code paths that are > plugged into core mm, causing itself even more special than shmem. While > it is a pretty decent and useful file system, efficient on supporting lar= ge > & statically allocated chunks of memory, it also added maintenance burden > due to having its own specific code paths spread all over the place. > > It went into a bit of a mess, and it is messed up enough to become a reas= on > to not accept new major features like what used to be proposed last year = to > map hugetlb pages in smaller sizes [1]. > > We all seem to agree something needs to be done to hugetlb, but it seems > still not as clear on what exactly, then people forgot about it and move > on, until hit it again. The problem didn't yet go away itself even if > nobody asks. > > Is it worthwhile to spend time do such work? Do we really need a fresh n= ew > hugetlb-v2 just to accept new features? What exactly need to be > generalized for hugetlb? Is huge_pte_offset() the culprit, or what else? > To what extent hugetlb is free to accept new features? > > The goal of such a session is trying to make it clearer on answering abov= e > questions. > > [1] https://lore.kernel.org/r/20230306191944.GA15773@monkey > > Thanks, > > -- > Peter Xu > >