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 B930EC54E58 for ; Tue, 26 Mar 2024 03:40:50 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 3A63D6B0085; Mon, 25 Mar 2024 23:40:50 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 32F976B008A; Mon, 25 Mar 2024 23:40:50 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 1F6CE6B0092; Mon, 25 Mar 2024 23:40:50 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id 10BA76B0085 for ; Mon, 25 Mar 2024 23:40:50 -0400 (EDT) Received: from smtpin15.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id 9EBDBC08C1 for ; Tue, 26 Mar 2024 03:40:49 +0000 (UTC) X-FDA: 81937788618.15.9CAA8C7 Received: from mail-vk1-f181.google.com (mail-vk1-f181.google.com [209.85.221.181]) by imf20.hostedemail.com (Postfix) with ESMTP id D214F1C0016 for ; Tue, 26 Mar 2024 03:40:47 +0000 (UTC) Authentication-Results: imf20.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=SoS+xM9x; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf20.hostedemail.com: domain of 21cnbao@gmail.com designates 209.85.221.181 as permitted sender) smtp.mailfrom=21cnbao@gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1711424447; 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=BAxJcJJJSqzqXQDoptd0DahWx5zMIhXhi5LktJiZIAo=; b=2oNXWIAabX1jaFml+lRySUpi0gz7dqa8wJS+jtMZBHUQOffL5h0jXb4mZ28WCtAmP/qTtO zB34pSJ3EZdHM0vb+JQvoKOoeg/eHGuF7gUlhSZuLSuzTp+w2c16zB7ihyjKWfnqJHmbXU hzTKFcrdNH9nXYBDWi83wVuU1Fi4tsE= ARC-Authentication-Results: i=1; imf20.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=SoS+xM9x; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf20.hostedemail.com: domain of 21cnbao@gmail.com designates 209.85.221.181 as permitted sender) smtp.mailfrom=21cnbao@gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1711424447; a=rsa-sha256; cv=none; b=GjDc2uKXKf0z73K2aIHvFP3PPuUQhBxpMOkVuQ2tSI/YistN8m/CpyvU80eTeJHUhCnHAy Gy/RWU2BPEJ8ilTtY2JxiwObQNP8LGyKnYghQ2vblxtY7PsDPcQx4nkHLmhu6DZM1wRLgu NEyiVEGy4d6mMjer0UvzCqpxsbD1FOA= Received: by mail-vk1-f181.google.com with SMTP id 71dfb90a1353d-4d4404fbdf5so1866570e0c.0 for ; Mon, 25 Mar 2024 20:40:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1711424447; x=1712029247; 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=BAxJcJJJSqzqXQDoptd0DahWx5zMIhXhi5LktJiZIAo=; b=SoS+xM9x1sqydHiH/jX4pTeWwGKTF9rDXT2cALQT539aEjfyF9BMt2ckstDRcswrSq XQxZEecUOhICcxdR7nw/kuu99YRL8mNm1WvSajB6AvCg8ToyuUJXUKWsxmMqEQWJsc76 pUUDNuiTL/Q1fxLJPQlyNLGuuG4lYC4/ucrVR0cDI0tOOV3VWhmEtQHdsfNrrayXFmbn cur0n+b/BUmEglb7IEP3jNdlngS43cOF59MIkQZRJt5r5lJeTZN5HgmZDFWCnxoEvP1t pfx5hTXj0nS/1pK92bwD3WTGF9tk5TtHcq5/7ZoaXxOBpOjL/IFI0zuVfB+wh/t0HASV J5/A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1711424447; x=1712029247; 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=BAxJcJJJSqzqXQDoptd0DahWx5zMIhXhi5LktJiZIAo=; b=VoQyXEm1MOgsGF4abjsUAQ5KnhSpP1gjyhPMrKP3TvdPkRhvk91SFqQCCxypVKmYgI Gh7bSxv7szdH8h0SXQS+A/xAHanjf1W0Yd6aeilo58NwlQ3OvMhmBNQKvJZ0IkBrdsoc mRodL69S0lzMioToZmG8HeZLDM/lGzjBUCfK3Y4SQEjNgHnsUuSY8OvPVnh+ISL4B9JT XTmFYb/YCY8JAKsZMI4inc8JPHnq4Bo3evtIkpNUNf3BiiDYXH/aV0OakUW038qhWzf2 VT9bRfcyPzh6Q+Y4AmuDnjnMbYcreF7aDD/2ihjvxRJbust+7mOJ/HuaiCH9yXeOEVem ofpQ== X-Forwarded-Encrypted: i=1; AJvYcCUlu4S71GiI9yke+TTmWD+fnlddFmqos5DYJOypQbA/TNJinen/RGmM60gOsBz+RUdadoStJXVo1R+fjdxZPbt3kss= X-Gm-Message-State: AOJu0YxM1JPFNO6T7oSaX5JhlvIMhP48mbtJNN7sTXVXdnNQ7LQYM3Iq oviaZqfKdVUSXPbUZiN4seVgiqjMXLRB+6aAT+yHuTOnD/Cke6UJROUt07FBVn7RrQnL+Rq31aB ih7P4gq8bGE2tksdxCKj9VqP3q0U= X-Google-Smtp-Source: AGHT+IGFyig3hsk7OpWB3oTBPEEQWZyDZimpv+2t38nkGnrrtlM/GFcMDiDtkwzhryXIRSHUX6rmu6TesMQOm9lLhaY= X-Received: by 2002:a05:6122:428b:b0:4d3:3f2b:dc63 with SMTP id cn11-20020a056122428b00b004d33f2bdc63mr1542703vkb.5.1711424445271; Mon, 25 Mar 2024 20:40:45 -0700 (PDT) MIME-Version: 1.0 References: <20240326030103.50678-1-21cnbao@gmail.com> In-Reply-To: From: Barry Song <21cnbao@gmail.com> Date: Tue, 26 Mar 2024 16:40:34 +1300 Message-ID: Subject: Re: [RFC PATCH] mm: show mthp_fault_alloc and mthp_fault_fallback of multi-size THPs To: Matthew Wilcox Cc: akpm@linux-foundation.org, linux-mm@kvack.org, ryan.roberts@arm.com, david@redhat.com, kasong@tencent.com, yuzhao@google.com, yosryahmed@google.com, cerasuolodomenico@gmail.com, surenb@google.com, Barry Song Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Server: rspam09 X-Rspamd-Queue-Id: D214F1C0016 X-Stat-Signature: ngut8ca5z5sqhzm7fszr1nednz94oiea X-Rspam-User: X-HE-Tag: 1711424447-441876 X-HE-Meta: U2FsdGVkX1+nbpJdrh6rt00wMosu1YmspazrYHPp2mIn98xo+uVF7ED7ePSNIYtfdk8h3csjJVjKOxHBnLQE+5/ivz4CbcmKPgP3KY5S6rtQ68iKOMOGer9Rfe8/RlDuoGSRjTZiGlSF3YuEJjQpO7HcHJtJmsX8aSCP/1q1f8rmq5GX5aZ6RAN0qoWd23jqYueQkX+VEDTWftpuO8qNWJ02aLZ+yT7JZTc3kvYK9TDEmJLwcvNt/CpJRINtjiw+ZG4MR4l5wlCGOlrD5u2thDCjgfxhs/a5MJGWG7HpbcVNGU0eY24OC809GF0LlcWuPzws3guqL7DxO3uk1Cp0Lk8FBEDj1T31OYrH+sCbp/5r55mQwOBsfKrawL7CFOpFk52aFyolSadzNGbZrzE8oTCc68zS1B1ehczgCcnHi5OQJDEDQI+US0qiCWdbKs3q+0/FJvYxoQkxUNtNjX0/SgHukbofKEyvG1rElhQL+8xoSrwiEc54F5zZPxusyO+FS0A8MjFzGYKZEBMv+pTAcyAmUW2tSvzTVO+1fBrbcwbkgII1bGk79U6ZtnGygE6zV6ZimTIy5Jup+NfRwac1jDDNuYI6mFMRiUBW9zcdzrTtHXctYrJvlpUx5LR5GNsXeMNrXI1ejJ+DzzA7Ni3/rikeb5Qz9V9/9yKG0RcS7q5npyi/RXfvIYv4pzKFeGylTCUjKfTegGoYAMcmB7sV7dDI/cvqJtPHLw5DoU7iWhv+c/kJxmv8SN+ly5pj2lrvz54XK87h5/TkK68i+/OqrqGGnCCirNmJuN1S6fqKd4Yhkq1PKPxoo9LPj4WX2Eqsulxk5kmlWPcG43IW2G5tBjxTO14GKjcBAZ+cT3lpN3f2N1IxYmKD3j1y+joCm36jRg1XQRs0jK3wFoaWjs7LVzjdJxqQ4x94fla9OYTyuWa89giLzuyYCjeUMhW+j/aZbBaOm+K7KTRzV4HFte6 tNsYjncn ff/9KDdtJWALkR8aXGTK0RPn9p9GJinRm3/REd0uKjWjCxEoibEeN48c3eQ86idFER7TiAX1fFsVggPW1SeIjuInur0zr8PoCArZOVMbc0O+LP3AjC3uUTYPRU2QRV4svqEADxBC21XIfIXBSB36Hmb067e7gvCBC9ctNbJqr1lFKLrRGn3/tSQmW5FDoZJyf0po4dFVvkquHHn98sJ/hBKJHNFlrnahjdZXfQMLp4PVzTQUSadRixtpW8iFkWhiDlRWV4Tq5t8aIPDDnMTbG0VNdWDTgWWsIx7DMJ5lFZ34Q3U1et+b1YgU0pOjuyCkkm2VuJVuHA0qO64qZZm8B2DSRqulzC7L06K11y/hIIUAvI9Q1XqgD9ZPHYjdV3MK14CX1UbO55Dqg+Emfy9rA3L/OR8IK7Bux2MMkHwEP6qPGrMXgYUZ8NRsvicYl1PWCWsPrYsEBQUyTIEA= X-Bogosity: Ham, tests=bogofilter, spamicity=0.055896, 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 Tue, Mar 26, 2024 at 4:25=E2=80=AFPM Matthew Wilcox wrote: > > On Tue, Mar 26, 2024 at 04:01:03PM +1300, Barry Song wrote: > > Profiling a system blindly with mTHP has become challenging due > > to the lack of visibility into its operations. While displaying > > additional statistics such as partial map/unmap actions may > > spark debate, presenting the success rate of mTHP allocations > > appears to be a straightforward and pressing need. > > Ummm ... no? Not like this anyway. It has the bad assumption that > "mTHP" only comes in one size. I had initially considered per-size allocation and fallback before sending the RFC. However, in order to prompt discussion and exploration into profiling possibilities, I opted to send the simplest code instead. We could consider two options for displaying per-size statistics. 1. A single file could be used to display data for all sizes. 1024KiB fault allocation: 1024KiB fault fallback: 512KiB fault allocation: 512KiB fault fallback: .... 64KiB fault allocation: 64KiB fault fallback: 2. A separate file for each size For example, /sys/kernel/debug/transparent_hugepage/hugepages-1024kB/vmstat /sys/kernel/debug/transparent_hugepage/hugepages-512kB/vmstat ... /sys/kernel/debug/transparent_hugepage/hugepages-64kB/vmstat While the latter option may seem more appealing, it presents a challenge in situations where a 512kB allocation may fallback to 256kB, yet a separat= e 256kB allocation succeeds. Demonstrating the connection that the successful 256kB allocation is actually a fallback from the 512kB allocation can be co= mplex especially if we begin to support per-VMA hints for mTHP sizes. Thanks Barry