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 C4529C47DD9 for ; Thu, 22 Feb 2024 22:17:25 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 46E9A6B0071; Thu, 22 Feb 2024 17:17:25 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 41F2C6B0074; Thu, 22 Feb 2024 17:17:25 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 2E64D6B0075; Thu, 22 Feb 2024 17:17:25 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0013.hostedemail.com [216.40.44.13]) by kanga.kvack.org (Postfix) with ESMTP id 1ECF86B0071 for ; Thu, 22 Feb 2024 17:17:25 -0500 (EST) Received: from smtpin13.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id C498D161003 for ; Thu, 22 Feb 2024 22:17:24 +0000 (UTC) X-FDA: 81820852008.13.569C97A Received: from mail-qt1-f177.google.com (mail-qt1-f177.google.com [209.85.160.177]) by imf06.hostedemail.com (Postfix) with ESMTP id 1D313180012 for ; Thu, 22 Feb 2024 22:17:22 +0000 (UTC) Authentication-Results: imf06.hostedemail.com; dkim=pass header.d=soleen-com.20230601.gappssmtp.com header.s=20230601 header.b=YlzRZFYc; dmarc=pass (policy=none) header.from=soleen.com; spf=pass (imf06.hostedemail.com: domain of pasha.tatashin@soleen.com designates 209.85.160.177 as permitted sender) smtp.mailfrom=pasha.tatashin@soleen.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1708640243; 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=Gh0r8xpDLECsgaX8QKSo59cMBX768h7l9wvXa5pRUj4=; b=DJOqMAuhwnMMvQodWr9cwKfHeEuPFLLIMAx9f/aFtPHW7CE2BYL5U2kAmEV3O5IdZP0W9U 2kBKs9FZgLHKt13d0HySC69EPc7jaxKsTBpwazbf5qbs/YUcIC/RoF1FonZQvLqCTEGAtI mzpW5gHyJRV7kVUeWa5dspG+3mhgaxo= ARC-Authentication-Results: i=1; imf06.hostedemail.com; dkim=pass header.d=soleen-com.20230601.gappssmtp.com header.s=20230601 header.b=YlzRZFYc; dmarc=pass (policy=none) header.from=soleen.com; spf=pass (imf06.hostedemail.com: domain of pasha.tatashin@soleen.com designates 209.85.160.177 as permitted sender) smtp.mailfrom=pasha.tatashin@soleen.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1708640243; a=rsa-sha256; cv=none; b=Fc2EgI7/m7dR1s+plch6kpt1hzCZFQyUMkVRPpSeGn9Bb1crIXEiYjbbTE5l2jMoWqSkLI WL+EHC/XHFwEoVrwGkvmsdyj/0sAk8oZSQIH2WadqKGc6hsEvuaNlfrR0iwl2ur3Zucii2 kUdCjl+5r8f5L31ShzpJKUS+PY6RKew= Received: by mail-qt1-f177.google.com with SMTP id d75a77b69052e-429de32dad9so554381cf.2 for ; Thu, 22 Feb 2024 14:17:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=soleen-com.20230601.gappssmtp.com; s=20230601; t=1708640242; x=1709245042; 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=Gh0r8xpDLECsgaX8QKSo59cMBX768h7l9wvXa5pRUj4=; b=YlzRZFYc8Xch6ytwwyltxbNPhCs4tCwQjajUcwQrRqtXsIteG0TvWAYyH3Jl2ONM3S 5MLJY5s+uRfYJmZEeaKb/3w3uoF974v67KRHjp6fgTEDg7oy+CtvO8SLEGmU+gqp4pyN RIdAqLEjULNBITXdd6xlOroHcyKfjBCyO9iyjg1tCj6kgQn9etef1aS0HA0RD3qLL6WN aOtzLzNwC4fgghrbP81KkD33IGEe19krzFAhSUuzv01arY4+uLX3C74g5uo4YKzIPcGE nTkccJbD3dxp8pz3FqItVlUx+7Hl52eelS1r5Yw6TfjCsyGL3mkoxPUHdW1m2Y9kIGgL KfKw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1708640242; x=1709245042; 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=Gh0r8xpDLECsgaX8QKSo59cMBX768h7l9wvXa5pRUj4=; b=Cyxy7FoKFRC/CWdg42a9QWdAv6hDI26b2WFObEvROztwEIye+AY8r+Urv0ONnV61ax Pz/j5JLWTsIqyKYmTTP5u3reCoCxXWM8r4yReUE38DmLwmgxz80fUOuNVeVCkR0LbZXL xrH/cONu4x3oPl+HTRe/XGYHZdEWtSJjcBD/5p/oaRWGdG8gIJNkCUZP1CmFcdgNC0v6 NdIUZ/x7yBrtMK3z3Ez+ONpmm6kQ0tX3KqjCLBK+bpzugr+eF3mCeYs9fLB6M2MdPhnc bIMy7EIJIsmx6VLDhU+AgXv9erFfAWDCUwvHuKzmWhKtQA2bPig7nsI5HWyCIC0j7W1B uKbw== X-Forwarded-Encrypted: i=1; AJvYcCUQ1w1iybLou0a+JZIqGwkxODA0Svu7GrnNOsch8LiowYbyj/qKz3ZKJLpVwjld6Wch3OSAnhhB/nW40CWkyBis0I4= X-Gm-Message-State: AOJu0YxGEp7Sr+ogVjLoaE4xT/X3P6EI7jc3xtyxue7CNZ1Yh4CgKFiM F8kojDxepL/AxbPHocgnVSoe9CY060AnjhF9T6izJkRv0z5e/XbwhIEG9tXffNyFtQz9wlZoY8/ 0+iuZer6Ep5IK6flAcAZHl92Hjq1trhgxVhqhtA== X-Google-Smtp-Source: AGHT+IEanQHpxgA1H3xcIHTC5j/yMY6OG3Y6wB0Tk5Kfzyhn8mW4eevR+9qlYaUVhGJC4bx9RUwhZFQsRkxqr7eYI9g= X-Received: by 2002:ac8:5fc2:0:b0:42a:b410:fa47 with SMTP id k2-20020ac85fc2000000b0042ab410fa47mr580049qta.17.1708640242144; Thu, 22 Feb 2024 14:17:22 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Pasha Tatashin Date: Thu, 22 Feb 2024 17:16:44 -0500 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: rspam09 X-Rspamd-Queue-Id: 1D313180012 X-Stat-Signature: fynh4aeyphhbai8b6yfipi5pjcgy13mq X-Rspam-User: X-HE-Tag: 1708640242-244931 X-HE-Meta: U2FsdGVkX18PgeDBqS3485PMRKcv15zFRMaRhpg4Ia3k6EAPXLpkeJORy9YQ9qGsnVC2tvfCQFhYAQMLprW2o4jsqzpyP0cgBcv9XSsrXgAawHReCTTlB0wcVpe5ikLHav9JTQNxuJw0Xr9WNeuHnSBVrW7lLNPlej/TgPfx852YDw5NKbrmr2nZ0QsBMQiddrRi8S2CfHSZncEXnNeq3BXo/Eu5JDB8w06/LXQwfXxsbSCHnMKOrO6uyc7Zw93YPr80FtAUQ6VgtFqvH+L0FDHy6MrkkTtyj88tnCBbnoQ7YnUMdhXnMQfghYBK4REKikdsRVbH0Fc7IowPl3nzlZqLkh+v2x+Q03BAJVaZJyaIdbOVPHSv0vBjTGsI36ar/rer8QiB50zza2QkjxY+LwojveUAkQRLYTwJxaUZTTw/X/zQ4CCGh1tU1escwkOILhWEXB/UGaxyVokZVikUnY8oz9+Xb4ZMQJDZY2Y0FNG7ey/rxkPqRj7O1fUgbFZsWdJkzSWGEtayj66D51NDiVGvy/weLotgs343uCrzikp9EKmiIO457VdfMI3NHPkUOBXIEmI8uqeGite2ZKpXSCOUkjSygkSce36wvUVnUXbhNHwGRNLOQoxPzf6knNC41AoWEIFyOtJAp8Ad23RwbMSRuK+xU/u902urQO2++0doK093YCKL6M9uFkDQOhAjG8cECO2FUPp4ojEGPUYss7/PKtQV65g3HoQ03TPMBOlbhNpzIKXC4gYhXSILTmbJ7hUkmDG8fxfPK13x56CYOzdUBoyJB0nPMXX8pnYSVrC53UWxhviOkgkEWrPtgyJ7jWIKllWNPvmcP0/dZFJWShi5+1VZVFHJXSUImDHdi4by2hIR4BXY0AkQfvmNc7dp5n3GR9kRJIBt3T2o3DKSxKyaOPSS6qC59NjU+MMD6Dof7yxRErB8w/ATpEMvXgbQ+tsDblHBcB/2+CEGNHF AzytHNXs wOsRmCF7C2lNgUI44/ZT+91880E4k+GGoirjoD6gAKUxSzyBwu6Yc+pWuaA== X-Bogosity: Ham, tests=bogofilter, spamicity=0.000330, 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, Feb 22, 2024 at 3:50=E2=80=AFAM Peter Xu wrote: > > I want to propose a session to discuss how we should unify hugetlb into > core mm. Or moving the interface part into a driver? > > 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 +1 I am interested in this discussion. Unification is indeed useful, and the core MM should ideally support only one kind of huge page. However, we must also ensure compatibility with the interfaces and features unique to hugetlb, such as boot-time reservation and vmemap optimizations. Generalizing these features could potentially lead to memory savings in THP as well. Pasha