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 AAF66C5AD49 for ; Mon, 26 May 2025 09:37:56 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 47E816B0089; Mon, 26 May 2025 05:37:56 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 455CA6B008A; Mon, 26 May 2025 05:37:56 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 36C126B0092; Mon, 26 May 2025 05:37:56 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id 18B576B0089 for ; Mon, 26 May 2025 05:37:56 -0400 (EDT) Received: from smtpin13.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id B3798BBA9A for ; Mon, 26 May 2025 09:37:55 +0000 (UTC) X-FDA: 83484557310.13.8967EBF Received: from mail-qv1-f49.google.com (mail-qv1-f49.google.com [209.85.219.49]) by imf22.hostedemail.com (Postfix) with ESMTP id D4DEDC0006 for ; Mon, 26 May 2025 09:37:53 +0000 (UTC) Authentication-Results: imf22.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=g2IAP1Kg; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf22.hostedemail.com: domain of laoar.shao@gmail.com designates 209.85.219.49 as permitted sender) smtp.mailfrom=laoar.shao@gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1748252273; 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=VpPIAXlYpFE2am0BQB+sd7iQJSZxXWCM2Ai0vvYdY6w=; b=5/gPOWp7ayFLRUil6G0NOR1TQNLnjWN4vWfGfJWOqX1vMZK1YF/CEXMoI4lbzv0O0ShJSB Wpv5Evf92mkuJruZSfspQpseMHlpOHBsSPLHcwLHz6rcst7Ftyn+PLxcJxcmat8gEojPDQ 9Tjv65e3HPrjkJoxOSax61K/1FBtEHA= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1748252273; a=rsa-sha256; cv=none; b=7mmk+MaLHrUIQB3bdHuRI5bPvLUdd4lRSEC/eyHxhfKW9aCqdDCKJi0s0RBrhcsRScovk9 86CMlnBm27r+cuBRTYGciQvDEXeGIGnb8bfkIgM6zdPdTlUKsck9BKpduR68YErlnuqNnJ cj1+DQT0Elst27sv4bvCNiNOveEW1ww= ARC-Authentication-Results: i=1; imf22.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=g2IAP1Kg; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf22.hostedemail.com: domain of laoar.shao@gmail.com designates 209.85.219.49 as permitted sender) smtp.mailfrom=laoar.shao@gmail.com Received: by mail-qv1-f49.google.com with SMTP id 6a1803df08f44-6f8d4375aa5so9088686d6.0 for ; Mon, 26 May 2025 02:37:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1748252273; x=1748857073; 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=VpPIAXlYpFE2am0BQB+sd7iQJSZxXWCM2Ai0vvYdY6w=; b=g2IAP1KgazBudBfg3UUn4wJvpqOKiBVLYhYVc8C0/GwPdToNsj41+F1/6yfxoQzk+o Q99LtTvcz6QBEM71WSUUyLbe+EI7nU05HfN/J+9l39NlPIqjKcMdybLx6GB9+XDt2MQ8 ZUPA83laY3JCJT4ISqGA9ZcOqaS5WDCYGrbXx0nnSmaEuf4oG4yg1e+EyyjnDFYE2KGo 2tXVqMA/7lAzuFT0t6VMRow2UUk+0Hje/ypTYa+zxnBPTgbBZ3lQSN6sTxBtBNNCMfby 47VVR5lY60SYBBh5ecKtbfCrZ8txuJL5e2m6zjbWK6v1NBYv5X7JUVP9ADsanF2iuM2S HU8A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1748252273; x=1748857073; 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=VpPIAXlYpFE2am0BQB+sd7iQJSZxXWCM2Ai0vvYdY6w=; b=FeyAwpa5Tc4uEV3fglZYSPW8wTtfU+UbkWf4BVD4dbJdrKyu1E9FIfsIjGbduWb2M6 MeYLISUH4MFiHc/ElGZdXKhwdadWZZ6SFdzuqa0g46rGbCSMtOSmBQOibGHXPPsTtMGi /dfXwnGl7YweKu4SpPA31CX5S1eSLYyDKd72k+JMmxfbC4Dt4epVvRJI+OYDHPwiPD3z OblmSjayZhoH5AjpCBGdykFTjJ4ju3yvDOG/nG+4cgbvKGJyvPxcnvksI1h9ma7VfYvE ihaQ5VksG1tvynOoisHEIQHpViYuY9gBOHgrwiXmj5HRjOwbfRnYKqXtmzJaYM3FYQ/O 3tvQ== X-Forwarded-Encrypted: i=1; AJvYcCWiEy4D/FasHj6vOKnNuzRYIKdCVYszmRLtOKrNk+SuG4P5uuooGE6tkyJAsIi+I0aALBslCgtokQ==@kvack.org X-Gm-Message-State: AOJu0Yw0G/gZuswqdtXm+6wk3810bTdvbMHjFZJ6bJSScHbvsGGLZhFO MxU4uY0ZN0gUWy662/mOAyeYP0oryGHdqrun/WnGhcQKC/tkaQBbVVkaBAikhEVVm0lX6b8BjPX NOnPYNEe+doPSe+QmG+VvURActOZnsQM= X-Gm-Gg: ASbGncvp3w3ArdVsTSdby7dWa6vCSw7TvwcWO0d0fy67kJXBi0xEOiafbmlX6CQfnhZ csARIPsGTBlv1qMWNY4SUj9TKupBdxUVHKVW3SE6FJhefUWMG3lbzAXrU4UQyTfq4xBLcpFLpZI qA1RooqvnrKtAdyzNt5T2jHuqHB6lSiXpXIg== X-Google-Smtp-Source: AGHT+IHFRegTp2MaOa67maX95yPRXcfxL5k4LhdvZZ8dYcwyIFGsOxCLC8HSR0yagAAojDRaxYiJkrfc1ziwJCFD47o= X-Received: by 2002:a05:6214:268a:b0:6e6:684f:7f78 with SMTP id 6a1803df08f44-6fa9cff2f69mr127386966d6.3.1748252272881; Mon, 26 May 2025 02:37:52 -0700 (PDT) MIME-Version: 1.0 References: <20250520060504.20251-1-laoar.shao@gmail.com> <7d8a9a5c-e0ef-4e36-9e1d-1ef8e853aed4@redhat.com> In-Reply-To: <7d8a9a5c-e0ef-4e36-9e1d-1ef8e853aed4@redhat.com> From: Yafang Shao Date: Mon, 26 May 2025 17:37:16 +0800 X-Gm-Features: AX0GCFtd1o2YYF7YjW_CC9HarRQ9vCcTbFUgfUfMqL9x9nt1OZbMdaro7AlINHc Message-ID: Subject: Re: [RFC PATCH v2 0/5] mm, bpf: BPF based THP adjustment To: David Hildenbrand Cc: akpm@linux-foundation.org, ziy@nvidia.com, baolin.wang@linux.alibaba.com, lorenzo.stoakes@oracle.com, Liam.Howlett@oracle.com, npache@redhat.com, ryan.roberts@arm.com, dev.jain@arm.com, hannes@cmpxchg.org, usamaarif642@gmail.com, gutierrez.asier@huawei-partners.com, willy@infradead.org, ast@kernel.org, daniel@iogearbox.net, andrii@kernel.org, bpf@vger.kernel.org, linux-mm@kvack.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Server: rspam10 X-Rspamd-Queue-Id: D4DEDC0006 X-Stat-Signature: whjhj7zw97z9a6tf3n8sftc7wjmxsnss X-Rspam-User: X-HE-Tag: 1748252273-415771 X-HE-Meta: U2FsdGVkX18pYWprqosVTEeLX5ncpUcXjprqOAODkEXuPi3xKHxFtyHcQztX/ZtTdmAljZDLcgy1MEtNEji7BJsPYNGnl94XZbZ6LWvbaRmKlD5m1nNHrkfpSa4zIy2NqKnexhESvQ3e15BN/CwWizYgv/k8CClSJlr9RalxBbvP7B1sd/z/WwShV5X41SN6n5ym7/MK+mXvtbHLEHhFVrLT3XTqA+8th2z0lluyfew5QNjTwirVEMfmunbhcWUC1loQFIYHme76r+kTbulGjE7h58godXpx14yvR8udQl/7Vz+R0kXOvn9W0p149gCrWMcKPrgQb3j06eah/sIxWtSY9izmNMsce+QGZDUfu07gJxJkjNE7seFA5Vb7Q5dJy5QKE1d2jXqnMymhsHT6Axwxydm/MOjQlBqp23hyKBm5GO7MTVH9l9jAI9tn0IM8ltaGAMZ/Zpq3d00vhkUq+UWzoTWKmnCJjslswxSm7OIeo6ZKdxr9EnDzudAt3O+CWJhzuyecDfFM4wnlwRRa+CTo+NkiKwGGzHRXgaH0Y2FMWenyzy9pt2f4HqjjKwhvPRdWJ0ZAbnpIOgx3ORb1lj8W9kHqxAYPqpXDHkgTNr6wJGp+sPl3+EFgviT6+94nACbaklc8mZnjKCBWTIcinnaEBGNSWxa4iINRvZPCyoP5y7PZZkFGzoEn0Lhsl1lIufUcUqfPUeM+hBmw2q53bNdUsB5Sax3AZgHaiHZ30uANaUNZY5AMpdrhAEyGkj6hBSTIvJ00glkBpAH5Nm74+RFv9by2fslf0TOTfTK/NC3q/ozEcWVAQvS0wgU49fmsULGYFiCDEqZ7uujOD/O1Zk4Rj0xTnPULY+Kg1AG4PvVtLbzEHaJyNHeFpcf32J6+QmHQZYDD/D5zfYnOP7iboh4qoWDjFzzN1e13LViLVfGc3/WES+l+Vm2BX0o12rs+Y2DVMiekth5wfAGsvWd rZZpZpJG vpLiQX34MmleP/3HBSQO+EmckV+I8McInDfqsUbg4Si3169RDM+vl1/6e+orPk+bPcBE/fbreFm4WPhIcFDmH1mQ97PZKlrNw7Z7svzxtPejA9ZkLXbKeKfbKml0vE6/SGEoP2gkNrJp15659ENGAsBjFJ7j70b/vVlZ7CoQyDGdg1EIOo+6LTfT6rnZ/OP8K7NK8Cr+HdSIJuVAcy9pPFQR+XTGwjIjrSpKoL+4P8aNkjelnNBLDWyCeJyCd8bY7MDM9shQK0mJqQy6NVWN8wyXoE5+jMzAx6jQUEhydJXTMKfW5KUGorwMJgPzWx+xPRkwv+QiJ1Rtx1L0BYn38HJQUU1IHkb3W+lRw8zd3rQXSPXrpYX2WP0KqBQ== 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 Mon, May 26, 2025 at 4:14=E2=80=AFPM David Hildenbrand wrote: > > > Hi all, > > > > Let=E2=80=99s summarize the current state of the discussion and identif= y how > > to move forward. > > > > - Global-Only Control is Not Viable > > We all seem to agree that a global-only control for THP is unwise. In > > practice, some workloads benefit from THP while others do not, so a > > one-size-fits-all approach doesn=E2=80=99t work. > > > > - Should We Use "Always" or "Madvise"? > > I suspect no one would choose 'always' in its current state. ;) > > IIRC, RHEL9 has the default set to "always" for a long time. good to know. > > I guess it really depends on how different the workloads are that you > are running on the same machine. Correct. If we want to enable THP for specific workloads without modifying the kernel, we must isolate them on dedicated servers. However, this approach wastes resources and is not an acceptable solution. > > > Both Lorenzo and David propose relying on the madvise mode. However,> > since madvise is an unprivileged userspace mechanism, any user can > > freely adjust their THP policy. This makes fine-grained control > > impossible without breaking userspace compatibility=E2=80=94an undesira= ble > > tradeoff. > > If required, we could look into a "sealing" mechanism, that would > essentially lock modification attempts performed by the process (i.e., > MADV_HUGEPAGE). If we don=E2=80=99t introduce a new THP mode and instead rely solely on madvise, the "sealing" mechanism could either violate the intended semantics of madvise(), or simply break madvise() entirely, right? > > The could be added on top of the current proposals that are flying > around, and could be done e.g., per-process. How about introducing a dedicated "process" mode? This would allow each process to use different THP modes=E2=80=94some in "always," others in "madvise," and the rest in "never." Future THP modes could also be added to this framework. --=20 Regards Yafang