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 8642DC48BEB for ; Thu, 22 Feb 2024 08:50:23 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 06B2C6B0075; Thu, 22 Feb 2024 03:50:23 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 01C626B0078; Thu, 22 Feb 2024 03:50:22 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id E23166B0085; Thu, 22 Feb 2024 03:50:22 -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 D024C6B0075 for ; Thu, 22 Feb 2024 03:50:22 -0500 (EST) Received: from smtpin06.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id 9CA4580CEF for ; Thu, 22 Feb 2024 08:50:22 +0000 (UTC) X-FDA: 81818818284.06.387A0A4 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by imf10.hostedemail.com (Postfix) with ESMTP id A90F8C0013 for ; Thu, 22 Feb 2024 08:50:20 +0000 (UTC) Authentication-Results: imf10.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=NRPfO6dY; spf=pass (imf10.hostedemail.com: domain of peterx@redhat.com designates 170.10.133.124 as permitted sender) smtp.mailfrom=peterx@redhat.com; dmarc=pass (policy=none) header.from=redhat.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1708591820; 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:in-reply-to: references:dkim-signature; bh=10LN1QbQfeSEX9facp3sR2zynhIQEfQ2yoFcs3DbVhE=; b=JCjjYly6oLhPLHZVd/5jS4nEIlfmJEhhKlDw6MvHEBTLeQjkjpkjT2tODoMseqYC782t+p aav/YLKvgqCxTjfBjgL6nmlWb0WYenOPFVwl3CGqUtx44FuhCR0gHiBAXMIgCvSI5awkVg ZijGOteNz7km7E9vNFiMXwK5/FxIFOc= ARC-Authentication-Results: i=1; imf10.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=NRPfO6dY; spf=pass (imf10.hostedemail.com: domain of peterx@redhat.com designates 170.10.133.124 as permitted sender) smtp.mailfrom=peterx@redhat.com; dmarc=pass (policy=none) header.from=redhat.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1708591820; a=rsa-sha256; cv=none; b=doquyp0u6dzrASF8FxaipSVenTyV6D613Zj/CN+7CDe+mrJi2488KkfAvOvV+si8G15adX Q51QhfsTwHEtztcmj60o66PFkr9V4UGDFH+WD4nhd6C2zwhE6hhE6dB/Ixh2qqE9CMip3F SxzgFZnDkE+R1Cr0Bztqf8/HMYfjnfI= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1708591819; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type; bh=10LN1QbQfeSEX9facp3sR2zynhIQEfQ2yoFcs3DbVhE=; b=NRPfO6dY+R8ZreU9I6uSFuLvTSsufRzm3tI9UCHKTk+1DcGFckMleNRVUraKWNzDW1/H21 VSEwrjazmBLmDXMazGL8Ifvk4RSyOH9mQN4khU4x6vHXSSv/7jmCggSVCZAToEu/W0/L91 ZHF4b+8RY9nUVds+18avZMHMt1vGMFo= Received: from mail-pf1-f200.google.com (mail-pf1-f200.google.com [209.85.210.200]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-338-8l020u0oN_C_UOhyjs0StQ-1; Thu, 22 Feb 2024 03:50:16 -0500 X-MC-Unique: 8l020u0oN_C_UOhyjs0StQ-1 Received: by mail-pf1-f200.google.com with SMTP id d2e1a72fcca58-6db0e05548fso2233383b3a.1 for ; Thu, 22 Feb 2024 00:50:16 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1708591815; x=1709196615; h=content-disposition:mime-version:message-id:subject:cc:to:from:date :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=10LN1QbQfeSEX9facp3sR2zynhIQEfQ2yoFcs3DbVhE=; b=l+nhw10L+H2LUoodDBZbSyinZ7Tz/w+ASB9ADnNNfiVr/jDVoZtSmcuv2REVeI2ov8 WTtARtida8aACunkMTJY9/2aVZ4oVTaGNqofVzgsj8rC83AS40DhZ4tIY7RbKsimmkbi +CAvlcU14l1E3WcQXtp28gwXlr9yUtvG5EDve/5BcBrNfL1dLFiIZ8zgG0O1mqQk+9CR OhvkNwZC+Y+rFSLrZXJtF1D1jMIkmtr3VR0MWXqfWoPqomDgTOeydwkZ7l49JBxfaz1+ B3Qqwy6H0ytwXUPxhbx2ui7hPJj3tb/VRb4tgDAgQs7/aZ/p/SvkbgmasRO9AyQ0JNFi BsJw== X-Gm-Message-State: AOJu0YyfHQVPquVmgRaN1aaLzdOeCbeMZTw38uDfuWOBgwFzPx7+jMJv kblnm3xmSMhB+YDe4Wp+3rDy3mo+H9DGMd+xwowGG9kRgdVYt5KgDscpdR8wi2+hTekXEc+GoNd uZX4uPoF4cWDdprOjjaPKV27Syev3XoH+whDbiqWs1NBYjoRW X-Received: by 2002:aa7:9dd0:0:b0:6e4:5e66:6824 with SMTP id g16-20020aa79dd0000000b006e45e666824mr12711778pfq.1.1708591815354; Thu, 22 Feb 2024 00:50:15 -0800 (PST) X-Google-Smtp-Source: AGHT+IEl1hYeU4tlUio/utcC6m7MCSTspTy4U5+Yo/X4qdWg//P+E1U+pWfoRrh0H3prvJX67fnI6g== X-Received: by 2002:aa7:9dd0:0:b0:6e4:5e66:6824 with SMTP id g16-20020aa79dd0000000b006e45e666824mr12711767pfq.1.1708591814993; Thu, 22 Feb 2024 00:50:14 -0800 (PST) Received: from x1n ([43.228.180.230]) by smtp.gmail.com with ESMTPSA id r26-20020aa79eda000000b006e118d2db9dsm1050542pfq.97.2024.02.22.00.50.13 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 22 Feb 2024 00:50:14 -0800 (PST) Date: Thu, 22 Feb 2024 16:50:08 +0800 From: Peter Xu To: lsf-pc@lists.linux-foundation.org Cc: linux-mm@kvack.org, James Houghton , Muchun Song Subject: [LSF/MM/BPF TOPIC] Hugetlb Unifications Message-ID: MIME-Version: 1.0 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=utf-8 Content-Disposition: inline X-Rspamd-Queue-Id: A90F8C0013 X-Rspam-User: X-Stat-Signature: 5nce7q6mbddcdizty9xx8pwu6tc7c6i8 X-Rspamd-Server: rspam01 X-HE-Tag: 1708591820-68714 X-HE-Meta: U2FsdGVkX1/2jwYuxm3Tss8ANR8pPXB0njLAtDUfz0zeO6ySY7RiF4IkV1Q3AzdRBLriNqbRqQSKWCPcOjKbuFG7qNW8WUbXAn+Xou3Dvc6++guFRcFaTul1mtaBS7+ZH1y+TJn3hk1yb/6yD6u/qAWmGgAI3ErEhtF2CIRUcihDTU2FCDER376eW41N2bJLGdvhByHtqxGAWwMNML0oAuyzyp0r5FYQlPZxId3oiv2evqH0XBS8+KY+eT6ky4JeRO8z6i7NrC+kRoIO+ylgwHjSGapSaeXfrRcjnzMUpFs+4RuxIiP3o7pUgAPgEmvdnNvKzv/fKtWcmJaG9QZoP9lqpubh2pT/5Mt1Pfd06fDAc4ShBnHFgSBAQnTwEWadvjnP3ncruAjo9vV9o9b6pzc+vF23xXF0hkxWy8JlKJZuU49BJsMKXdCU7/PaMRxpvRqTIYz7U+jhcTeNJwiKqDm44FB2jzI9fpO3XHOcWFq3KIAORaUzlHm0mjgs11n1AjYaNhgtFaobqqSL2YzAPYIVYydV9W0S3nAOrZ+8RKFR9nFrjaxCqnP7DdBOI59winE0QwMpX5oPh6nFGSHFvrY1LcwGNYs9DIp3ZQ7uL8aqKUBjLjyIzUfBxs372V+69XQo4uLVXs1/RT1Oi4DMQdEsoBaYZYm7AHbK68+iGhO05BMCn5eTs5D8SAPMyr2z4y/bqmVm4X0XttAu6FyBLEjortyaABCOXRd/80DCZGDy4W2I75etKTU4aqdushFVaBa5Ft78SbZ5kcuSTDm239sg7Ro65rCosYlyIAk96fFPBPTm313rT6I65M0/DYmL9O6RBM4ShtZErXWitRFVF4fWYDY9ljno79zdDY+xQatSpOO1/LrdVlJH5Ha1FM7sgDDQJJv1RaPP9PY59Q5UXVsSm2ueknWdqbqTGvlvtfkd2g4YnIt837cgyxc+yntnIoN6lMnJdm0cmkdvVdI 14pBw2rQ sUR9UqEynKvDTpEGG6qROEwF3DWiQst8Ak6VUb+zz7+kgckliGuxzkQFnlW4hK4Zz7srz+2/EZ1iT7glnRYzg2nJHBRCrVJdmbDQ47xf1mWTBzEqmi+Ko3CUosRIZMzp+QbEhhvCwsK0LOOujyaBbvHPKEkgk72of+pSBtMpd2qRBKRCpHKXsuRNXMfJdxwIIxksSwA9Msj08avie16gxLtPRA/tbkSa+Xq3JAEx+xGYi8Er3BeDrbeXRtyKfVQgqFdPR2Tflok9H5LaObw9pz/w1JQG182eScEIH6KBC9WGp+BMauoSGc7haC4xGvi3sw8Tc3GuNjBo1/xGgqTY3av1LedprynbtGpZWi4ZzixTT5fCIVjKWJhAR+ggzqblOB1yaxflxKF1vfnshNt2M/KSCWi8J70eWcvOnptgt4G0MEIGo2Uc1yCkKF43vM0ePSpEjD5Ge6aL8aIfQDg/6ucT3enUSc7mMpGLb 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: 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 large & 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 reason 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 new 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 above questions. [1] https://lore.kernel.org/r/20230306191944.GA15773@monkey Thanks, -- Peter Xu