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 F3DDEC25B74 for ; Sun, 2 Jun 2024 04:36:30 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 729D96B00A3; Sun, 2 Jun 2024 00:36:30 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 6D9F96B00A4; Sun, 2 Jun 2024 00:36:30 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 57B766B00A5; Sun, 2 Jun 2024 00:36:30 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0016.hostedemail.com [216.40.44.16]) by kanga.kvack.org (Postfix) with ESMTP id 385DE6B00A3 for ; Sun, 2 Jun 2024 00:36:30 -0400 (EDT) Received: from smtpin17.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id B59F4C01E5 for ; Sun, 2 Jun 2024 04:36:29 +0000 (UTC) X-FDA: 82184687298.17.E1B23EC Received: from out30-133.freemail.mail.aliyun.com (out30-133.freemail.mail.aliyun.com [115.124.30.133]) by imf09.hostedemail.com (Postfix) with ESMTP id 24ECD140004 for ; Sun, 2 Jun 2024 04:36:25 +0000 (UTC) Authentication-Results: imf09.hostedemail.com; dkim=pass header.d=linux.alibaba.com header.s=default header.b=FEHN1nRn; spf=pass (imf09.hostedemail.com: domain of baolin.wang@linux.alibaba.com designates 115.124.30.133 as permitted sender) smtp.mailfrom=baolin.wang@linux.alibaba.com; dmarc=pass (policy=none) header.from=linux.alibaba.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1717302987; 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=ZNZ5EiYzI8ePykWRaBhiaORawPDBRtocLTQhbcC0T/w=; b=EGmzdhlpc/6rbrRppi43IWtA6wQ0NhxJ7NClNUy+81htZrgqganKbzWRosjhA6Et1tnOZA HGprPSsiyrPWjWGMdV3SmKGVqa/tFwZ/rv1rdJmGsQAMzpQhPH/otxL/jv6oQqWeP4TQnn 8hFOxaOM5oO3y15vIeF6GpjCLDF14Fg= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1717302987; a=rsa-sha256; cv=none; b=LM5uglwRJ22C1Q1hnAlq7ST+4+rwNA9r31B6200gLGzyJHEjOTjM2B3f7USSOOR+xZc9id dXCWHLzo/iqQ8P16b6quA+BT9cDlYqluuqp3OKsAsj59Lz3FfbP1YRMcT/lA1QhCPHiZDr LJoycnSMIaIzJU58Px+Hv8PhUxbVwHI= ARC-Authentication-Results: i=1; imf09.hostedemail.com; dkim=pass header.d=linux.alibaba.com header.s=default header.b=FEHN1nRn; spf=pass (imf09.hostedemail.com: domain of baolin.wang@linux.alibaba.com designates 115.124.30.133 as permitted sender) smtp.mailfrom=baolin.wang@linux.alibaba.com; dmarc=pass (policy=none) header.from=linux.alibaba.com DKIM-Signature:v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.alibaba.com; s=default; t=1717302982; h=Message-ID:Date:MIME-Version:Subject:To:From:Content-Type; bh=ZNZ5EiYzI8ePykWRaBhiaORawPDBRtocLTQhbcC0T/w=; b=FEHN1nRn1puAFSI+i6Zu38oESEiwV+b2RriNm6p1e3tw1PRn7RlINGzWwvqPh1rW7uyw7hZFrRd/xs8W7ehpeh8ZWkzxumDoMD36Cz96eXi/kwfFOB+zWhfb1aZeBYtGUg2PgOpsqfpA76tnT3VeTzHPFGomzyElLn//yjFwLMw= X-Alimail-AntiSpam:AC=PASS;BC=-1|-1;BR=01201311R161e4;CH=green;DM=||false|;DS=||;FP=0|-1|-1|-1|0|-1|-1|-1;HT=maildocker-contentspam033037067111;MF=baolin.wang@linux.alibaba.com;NM=1;PH=DS;RN=16;SR=0;TI=SMTPD_---0W7dxKvB_1717302980; Received: from 192.168.0.106(mailfrom:baolin.wang@linux.alibaba.com fp:SMTPD_---0W7dxKvB_1717302980) by smtp.aliyun-inc.com; Sun, 02 Jun 2024 12:36:21 +0800 Message-ID: Date: Sun, 2 Jun 2024 12:36:19 +0800 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v3 3/6] mm: shmem: add multi-size THP sysfs interface for anonymous shmem To: wang wei Cc: akpm@linux-foundation.org, hughd@google.com, willy@infradead.org, david@redhat.com, wangkefeng.wang@huawei.com, ying.huang@intel.com, 21cnbao@gmail.com, ryan.roberts@arm.com, shy828301@gmail.com, ziy@nvidia.com, ioworker0@gmail.com, da.gomez@samsung.com, p.raghav@samsung.com, linux-mm@kvack.org, linux-kernel@vger.kernel.org References: <716c515156e8c891766d8fd3f1df231d289b2a37.1717033868.git.baolin.wang@linux.alibaba.com> <4e918c74.1262.18fd1d870d6.Coremail.a929244872@163.com> From: Baolin Wang In-Reply-To: <4e918c74.1262.18fd1d870d6.Coremail.a929244872@163.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Rspamd-Server: rspam03 X-Rspamd-Queue-Id: 24ECD140004 X-Rspam-User: X-Stat-Signature: tffefybjkkfjxq19xqq9nf6xq3mujnyu X-HE-Tag: 1717302985-78182 X-HE-Meta: U2FsdGVkX18ye9BdDwj5vIFaj2IjYoEZGJFdRu9VOKLAUv+XW1OjOpv6Hb6hQeq7EmXZo43XffODu3bkyXjnifcH37DsAFid4BENLxtsdkChBpMbjHesuIhUmPGNW9lKwa7/kMbtReFPHtUkst48sZgl410qkPhR5aqS9HAUT9Mtcm4+yqtmTy3YS2gvDqpo/sq/y4ULL99Clq99+ea6EkTdlK35imbAJ6sHBCHdaEtrWZTA0Z0WoHtXIhRVR+N+xjzg4aMjRfYE/qNEshhbuGGX5X7+HAVgaN0YWKhLK/+JMsTRmmicDYxrC9XJLGEAosyWcsR14ToGLA1RTlO5fm7Q0jk4oS6HfURTPILsl+JrtMaENnl/jnjGqOJrWsqty2Kgl2EXV5jAT+ruNOYenrv+i/L1By9rG7yj2FMQTAf0QwtdVoQ17428C77WLb5D3OZo+Y/bo3sQv4iuW75Fowd4SseNXeV+RnGcUruWrOXc6zSgajrkHFyIHAYCddfZofdRPp9L70CjGFS11oovqCS3H9LHeuczH1YW5KqabmW23lWKJvAyllohr4YyICd1klzzw6ZInJUjDsGaVVXrkgej6s62FDpBY1LFCj421yudaBHy4LnxvjtQclOtpZa+7zTbwugqfMPMnN1MnnlaKmgiCpNxssLwXO9MpgMGvHoxHGxMjS1PjsT8hj71LSHek61v5R9ecLx6Gq0zy8vj68VyemaBtVKsnkQGk6FUV6yiGoHTdnC9tG+sSsoVogcIeBLeX0uuPKkz5y017VRfPqfDdTm6Ow+gkL1P2YdCi8x+58pXI4zUCHm0fVArdqkLw+WllyjpgsRFmIa+8iGl+1uMnItLURc/yKyPvHB3qVc6plrIR+T+VlLpNY8b7cfsW9XvH1ymiSrrUCPojN5Ma2xPZeaZAu/psjlk6l48lhUaVQzHJdutGsuM1Ofv6c5/6V1EGYabIkZ6doRcopd kmaOWCbu INMJDIIFWhabHpo1UpOUATQO7d5X41SQnNX5fWb8YC7yfeXArPx1qeXVmx1yHSyOtCDyWfepYf4wWDi0O+/ljTTd8dHF6Ttcbuof6aZhqEJfHR9MnwZOmxbqqJ1/tKKRSBmIJqwSICO7UIhRA5hbUKtStzAS5z2wAQvWbkM+UDqJ+cZX0vV/LhDWdA+b7T1RvoRJR49cx9tNSXk8iTQH9AKbjbNYHTkjTcQFtWOgI0+LJ2ccKRqN6lTHWkOjNQyAullQffq+/xn8iQwuI1dmwNAYFzsZCb2uKHg/vJmI+hXvfm2lWQl9/2YURpJu7xGuhbJq9FBdodf5gSfdCiB6nPN4ZCKI7jHnwbcxUC94k/1sL9WfNVviywvSC6Q== 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 2024/6/1 11:29, wang wei wrote: > At 2024-05-30 10:04:14, "Baolin Wang" wrote: > >>To support the use of mTHP with anonymous shmem, add a new sysfs interface >>'shmem_enabled' in the '/sys/kernel/mm/transparent_hugepage/hugepages-kB/' >>directory for each mTHP to control whether shmem is enabled for that mTHP, >>with a value similar to the top level 'shmem_enabled', which can be set to: >>"always", "inherit (to inherit the top level setting)", "within_size", "advise", >>"never", "deny", "force". These values follow the same semantics as the top >>level, except the 'deny' is equivalent to 'never', and 'force' is equivalent >>to 'always' to keep compatibility. >> >>By default, PMD-sized hugepages have enabled="inherit" and all other hugepage >>sizes have enabled="never" for '/sys/kernel/mm/transparent_hugepage/hugepages-xxkB/shmem_enabled'. >> >>In addition, if top level value is 'force', then only PMD-sized hugepages >>have enabled="inherit", otherwise configuration will be failed and vice versa. >>That means now we will avoid using non-PMD sized THP to override the global >>huge allocation. >> >>Signed-off-by: Baolin Wang >>--- >> Documentation/admin-guide/mm/transhuge.rst | 29 +++++++ >> include/linux/huge_mm.h | 10 +++ >> mm/huge_memory.c | 11 +-- >> mm/shmem.c | 96 ++++++++++++++++++++++ >> 4 files changed, 138 insertions(+), 8 deletions(-) >> >>diff --git a/Documentation/admin-guide/mm/transhuge.rst b/Documentation/admin-guide/mm/transhuge.rst >>index d414d3f5592a..659459374032 100644 >>--- a/Documentation/admin-guide/mm/transhuge.rst >>+++ b/Documentation/admin-guide/mm/transhuge.rst >>@@ -332,6 +332,35 @@ deny >> force >> Force the huge option on for all - very useful for testing; >> >>+Anonymous shmem can also use "multi-size THP" (mTHP) by adding a new sysfs knob >>+to control mTHP allocation: /sys/kernel/mm/transparent_hugepage/hugepages-kB/shmem_enabled. >>+Its value for each mTHP is essentially consistent with the global setting, except >>+for the addition of 'inherit' to ensure compatibility with the global settings. >>+always >>+ Attempt to allocate huge pages every time we need a new page; >>+ >>+inherit >>+ Inherit the top-level "shmem_enabled" value. By default, PMD-sized hugepages >>+ have enabled="inherit" and all other hugepage sizes have enabled="never"; >>+ >>+never >>+ Do not allocate huge pages; >>+ >>+within_size >>+ Only allocate huge page if it will be fully within i_size. >>+ Also respect fadvise()/madvise() hints; >>+ >>+advise >>+ Only allocate huge pages if requested with fadvise()/madvise(); >>+ >>+deny >>+ Has the same semantics as 'never', now mTHP allocation policy is only >>+ used for anonymous shmem and no not override tmpfs. >>+ >>+force >>+ Has the same semantics as 'always', now mTHP allocation policy is only >>+ used for anonymous shmem and no not override tmpfs. > >+ > > I just briefly reviewed the discussion about the value of > hugepages-kB/shmem_enabled > in V1 [PATCH 5/8]. Is there a conclusion now? Maybe I left out some > important information. You can refer to the this patch's commit message and documentation, which are based on the conclusions of previous discussions. In addition, you can also read more discussions from the last bi-weekly MM meeting[1], summarized by David. [1] https://lore.kernel.org/all/f1783ff0-65bd-4b2b-8952-52b6822a0835@redhat.com/#t