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 666B9CD11DF for ; Tue, 26 Mar 2024 22:19:27 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id C3E9B6B0088; Tue, 26 Mar 2024 18:19:26 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id BEF2A6B0089; Tue, 26 Mar 2024 18:19:26 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id AB6916B0092; Tue, 26 Mar 2024 18:19:26 -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 9C1136B0088 for ; Tue, 26 Mar 2024 18:19:26 -0400 (EDT) Received: from smtpin09.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id D78371207B5 for ; Tue, 26 Mar 2024 22:19:25 +0000 (UTC) X-FDA: 81940607490.09.B782940 Received: from mail-vk1-f175.google.com (mail-vk1-f175.google.com [209.85.221.175]) by imf01.hostedemail.com (Postfix) with ESMTP id 19BFC40015 for ; Tue, 26 Mar 2024 22:19:23 +0000 (UTC) Authentication-Results: imf01.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=I7mtNjID; spf=pass (imf01.hostedemail.com: domain of 21cnbao@gmail.com designates 209.85.221.175 as permitted sender) smtp.mailfrom=21cnbao@gmail.com; dmarc=pass (policy=none) header.from=gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1711491564; 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=uVlAHvB0SWTJSq96zzqPEWLGZJRYckKxI8g9WYksFxM=; b=INI5fsFXzCCdxsya32dz3nEcTYN36Goni1l7RW5e8JAkvIRc8wp8TJsT7mAvhRNf9lADXI kqZLyu2Xm6ip1SbGXPx09l+oahevy6l5osnOkgZqKDaWgx83UVICIStPjYqjZI7Wm7P/yD /yY64/bAzehXyAKATwWqy+Qfbor+Ge8= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1711491564; a=rsa-sha256; cv=none; b=4/Z+YLhO/DWZOodWX2Nd7Hcbd0JqE+NhkTAxCsLwjHtn8uFsXLMt2pw+D7nldwEXcQ1qIn s88jWTGLj4VbeBP1zgkul+hdT963TFIqmcL9nUSjYp5ExdJQImm4+xK8oOrNpX8RxIEpDq z1+2gVMu9zyrPTbCyV3UVU7xO5tbqeo= ARC-Authentication-Results: i=1; imf01.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=I7mtNjID; spf=pass (imf01.hostedemail.com: domain of 21cnbao@gmail.com designates 209.85.221.175 as permitted sender) smtp.mailfrom=21cnbao@gmail.com; dmarc=pass (policy=none) header.from=gmail.com Received: by mail-vk1-f175.google.com with SMTP id 71dfb90a1353d-4d453ae6af5so2420029e0c.2 for ; Tue, 26 Mar 2024 15:19:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1711491563; x=1712096363; 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=uVlAHvB0SWTJSq96zzqPEWLGZJRYckKxI8g9WYksFxM=; b=I7mtNjIDbs69apf/Io0CMMouT29ne2CpzIDIqeHZ4o64L4owoABkaDYpB4lGO2iuAH bw7WKKXa0Wsx56LpqdpYbnnoIu/w070Zq+RZ7qxQaKrqV3HffsMXUF3L5jqurLx8gtQM adbVitjvn07cbHIEzBCsOYom/ZCIHyLJ+grJ9TwEEk3041XAAJOs3THQKHnKU9kiteEr oT1MlyKZrRlj9RIuWvJRmWycXfhgksIX7rBp9ptTUJHqtC6hQ+75hsQQKHsctnauw7rk PJd5nmK3MNRsTbPhia7c4C6XX54PTh71GYypFo6rOVlDEssZd+Uq6vwEqX4AtSxirXcD UnmQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1711491563; x=1712096363; 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=uVlAHvB0SWTJSq96zzqPEWLGZJRYckKxI8g9WYksFxM=; b=DqLyTux6mBp/114o1XEuXhWUVzEJi+Btjj7gfa4guRlLI8K79khCO20iN/Z4D9ZYsR loPDQNOdRQejEY6YOQ0htRNwe5pYwWiKn3g9J6etiV8McLmOaU9YNlODSmrZC+o59gxh upbnvZlOtpoYtd7kO8npe0J7N1PZKr1kzmZB5ZfxswJXcuMXdM9r5B17PA3ASOYfVEvW edISKVjHDuVOhvcbwSjMcbijADfxsgnwzp8bJ7rxhMfxRC5gesFVw17DU8WmvMVmW/2h UTOPKgB4RumOiqs0mk9kezqr2CXu1APWhbMjjlWgbTn2rhylFXpz9WeRx3HH4W+BMimu LMhg== X-Forwarded-Encrypted: i=1; AJvYcCU1uzsu8oG/JyXLmaO3tDdbhQt3P4NIPAKvKNE6yqmbg9En7XqGZCDkmKA2ag4ZroBwZHYLlkMSbgEKiTbq3JXzyTs= X-Gm-Message-State: AOJu0Yxl7YJgDb6GplWLwhGNFhmTV/+RdbfyIC0fQh640dci8GHg+kUX GBjMiD717YGZxjgtt3FjTVZxg7KSVkCgp5HPMC1w1azcLZJP4xnZauqkFrTYHyUDYYaLKk9YhQG nO8RL8FlfaABEW8posKYTvIVEIl0= X-Google-Smtp-Source: AGHT+IHpC6kZYUz0iFTINv5ReZC8Yx9b/zERt8p6PzjfIwXJlGn7QEe+l7yE0atHtSFKvBNpOlL55a2vFWIqOZWiTHg= X-Received: by 2002:a05:6102:f11:b0:476:fb70:9d24 with SMTP id v17-20020a0561020f1100b00476fb709d24mr5028373vss.23.1711491563026; Tue, 26 Mar 2024 15:19:23 -0700 (PDT) MIME-Version: 1.0 References: <20240326030103.50678-1-21cnbao@gmail.com> In-Reply-To: From: Barry Song <21cnbao@gmail.com> Date: Wed, 27 Mar 2024 11:19:11 +1300 Message-ID: Subject: Re: [RFC PATCH] mm: show mthp_fault_alloc and mthp_fault_fallback of multi-size THPs To: Matthew Wilcox , david@redhat.com, ryan.roberts@arm.com, yuzhao@google.com Cc: akpm@linux-foundation.org, linux-mm@kvack.org, kasong@tencent.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-Queue-Id: 19BFC40015 X-Rspam-User: X-Stat-Signature: ycdjz18fqqzggy3ngetkxrq6uw8y5eke X-Rspamd-Server: rspam03 X-HE-Tag: 1711491563-442931 X-HE-Meta: U2FsdGVkX18DYnS4bQHm+RXnf+GFbvliPyxE79PhmErQmy4bvpRwDp9qDOv4m6F0CHTVJ4lvBXW3+EtXe56g+b06f4jaYUE9bSpr+Bh67HTLBSkS+sTpSibxkbthp9iQ1N0nQrjf74nC9oFmmJKrbAAP7Fz3WrsFnwHWq081t8/TRRJCoYdXLnAv90Jqg0lkB/bjd4YCsRQUWMf6b/pIRJKUUxvYUYC/FiQP/z91Y7tFxAqQWH5tocr8BdJ6rqwe4UVXPFRihti7y9XvbUO4L4zxu4csV1xkS+RpCXWEwtkSPf+gu6jKr/Jdpwpqh6F/RyY0foW1wXZW5Pgq0t7uo2yveSTzCdq/Lvsn+LTdnSuQlucRNIoT4W2d8pxaqGvrScyeT7l2j4nSMX1QzGbWdyIZnTzD7UlWzDhOZMd2IiFnknhuAGTIzVrR4QmZnga668fmqkPmRZ6wD0y6V8J0p7KtpkgiWwkbnxxcOEFlY33tOA6/1rjhsvJJRyGXgGw4JJx+3SMMts3+uSJAwr+zKqru3Cu1YM4B1IDs6GL0SBWRew2Fx1qS+8syMZNEUjA7IImBjZT2Oa0rSzqjhfCI7VQTwJvnvdPbrE9Yv1jUW+IDgatV8GkfSLNWXUhtdzCuQGLJ/hEUxkPC1rt2avXfROgyj5WyCeL+JhDirtn4k92WbVq3kCHG5uTF98DKcjhU+7Rq6KEC4T/upy+JIwUsOGcolMf/7T8lJhqpudKXct0oyx6daSIWArsxBaST9AO/rCYJurcPkpmGHp4ZVdeLj+jI5fnat82+VG/wAum6UEXlQ0mBXZz22cShlbkW9d2dLi4xeovQkpM0Wz3JP0Q0QLWdizSpHHMBmBg2enStEF0/LB5B/sxPjCmVyXBJ8GpWIVTBEsUY72lsdKvsWhmcT7k5SP9kLWRpofytYP3APZQ/6a+RwIDCc5n0BnlYbDhXk51knnrAvXU3O9m2rqG vy8mrCG6 k3eo4UGSxM0bHRpNvHPcAlx6Orqb0dv16bXfP1U++ed/iwzxiXVj6/eNqL7sG7mmuhu0OYUufcBa/Wy+sv54XN6tWhV8Ufd0ego+/f5nqZC2ncGyjiuluaegEoWe2lW+9E8vDQssu14mjiP8vVUz09AS+4h+zVCM8s9R4zqEwGXYxz9mMkQDQgQ8t9MthfWPg3uYXbeieZNcCe9DUgKZUeGZ0jKCBwiEd1M+sAxkbV+cyWPzmhEfflJZHcfgpvjf2SwWJrBEVaoTfOHy//S9SRjeJozgK9+DJKt5wWa89TF6vxCFkQTCczw56a4ZFr0hyYUcNm+RTL1PX+NCBA6mNCJAsM5/yGGmiVkhTrWXNjoHlx+G8WbSwZjvn/Q2NY+nBfX0xAlbKnUk4z1uMoO15C7QqsaM4DRI5uMmC0XwNara365210QvDoXT0KqOJrRl5QubHjmeL1ES9ZgnmxkkQtIDo8i1RGPLFN6TsmOSsaYXx1+4mVccUfQcIzkcDVElfCK6ry/8j48vtPayABPICcgZAKYbvDot1yEThANqQ9Fp1ejcdVWe/JGjomA== 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 Tue, Mar 26, 2024 at 4:40=E2=80=AFPM Barry Song <21cnbao@gmail.com> wrot= e: > > 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 sendin= g > 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 > Hi Ryan, David, Willy, Yu, I'm collecting feedback on whether you'd prefer access to something similar to /sys/kernel/debug/transparent_hugepage/hugepages-/stat to help determine the direction to take for this patch. This is important to us because we're keen on understanding how often folios allocations fail on a system with limited memory, such as a phone. Presently, I've observed a success rate of under 8% for 64KiB allocations. Yet, integrating Yu's TAO optimization [1] and establishing an 800MiB nomerge zone on a phone with 8GiB memory, there's a substantial enhancement in the success rate, reaching approximately 40%. I'm still fine-tuning the optimal size for the zone. [1] https://lore.kernel.org/linux-mm/20240229183436.4110845-1-yuzhao@google= .com/ > While the latter option may seem more appealing, it presents a challenge > in situations where a 512kB allocation may fallback to 256kB, yet a separ= ate > 256kB allocation succeeds. Demonstrating the connection that the successf= ul > 256kB allocation is actually a fallback from the 512kB allocation can be = complex > especially if we begin to support per-VMA hints for mTHP sizes. > Thanks Barry