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 41B56D68BDA for ; Sat, 16 Nov 2024 03:00:24 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 740119C001A; Fri, 15 Nov 2024 22:00:23 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 6C7FD9C0018; Fri, 15 Nov 2024 22:00:23 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 51C2F9C001A; Fri, 15 Nov 2024 22:00:23 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0014.hostedemail.com [216.40.44.14]) by kanga.kvack.org (Postfix) with ESMTP id 2B54F9C0018 for ; Fri, 15 Nov 2024 22:00:23 -0500 (EST) Received: from smtpin10.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id CD5341A0E54 for ; Sat, 16 Nov 2024 03:00:22 +0000 (UTC) X-FDA: 82790453256.10.DF03F66 Received: from out30-131.freemail.mail.aliyun.com (out30-131.freemail.mail.aliyun.com [115.124.30.131]) by imf26.hostedemail.com (Postfix) with ESMTP id 2129F140027 for ; Sat, 16 Nov 2024 02:59:44 +0000 (UTC) Authentication-Results: imf26.hostedemail.com; dkim=pass header.d=linux.alibaba.com header.s=default header.b=XAIaaf1e; dmarc=pass (policy=none) header.from=linux.alibaba.com; spf=pass (imf26.hostedemail.com: domain of baolin.wang@linux.alibaba.com designates 115.124.30.131 as permitted sender) smtp.mailfrom=baolin.wang@linux.alibaba.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1731725889; a=rsa-sha256; cv=none; b=VDmdQuWW5zmeT9UVg8gmm8eK+WY1CKdjVh43Ejg0ciwBBsebePTmTnLaEtMYS0HjQjUwod v73YpQUWXhxogMnAILOVanwqMr596qpBqQ76x7mNXrG6mjGV9EFUvA+ZqCCvmo47WTLFmL SW8aP6+Zjp+Z7mE/Z+htXaAFfpu9Cnc= ARC-Authentication-Results: i=1; imf26.hostedemail.com; dkim=pass header.d=linux.alibaba.com header.s=default header.b=XAIaaf1e; dmarc=pass (policy=none) header.from=linux.alibaba.com; spf=pass (imf26.hostedemail.com: domain of baolin.wang@linux.alibaba.com designates 115.124.30.131 as permitted sender) smtp.mailfrom=baolin.wang@linux.alibaba.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1731725889; 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=H9UBLlphCdhVZDzQqhowJ1Buh+3zpa4QHzk+DvFyodM=; b=nGLyENO2ummx5XKuMe0mysQzETM066hgC8fviiOahYxH0LddzYy70UhXAfVmUGGzWucJ3o eS7ZRzjmxo07VhSr6TSp4ZvQS4sjuo5N9d0wbEZW/uGafzEHhXvkj5G/Hj7BLXxTtpssuG fBBJVhSFfufsNvrEdnCek3ENUulf+C4= DKIM-Signature:v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.alibaba.com; s=default; t=1731726017; h=Message-ID:Date:MIME-Version:Subject:To:From:Content-Type; bh=H9UBLlphCdhVZDzQqhowJ1Buh+3zpa4QHzk+DvFyodM=; b=XAIaaf1emIxD+lvlH1za0WyPob0p61F3qgflwWkN2WguMDkDGIRr29eTIRJdoOaSD8kp45xweGWKzwcxl//CYS1mhtVklD8ONNn8jA7zYynKTePNEQpV1HNRFYlT4+y8fcOLy/MwDJq+gNIqCmnO5R7CHE/s+a1zdb9yLZzvceQ= Received: from 30.121.23.212(mailfrom:baolin.wang@linux.alibaba.com fp:SMTPD_---0WJVKSl3_1731726014 cluster:ay36) by smtp.aliyun-inc.com; Sat, 16 Nov 2024 11:00:15 +0800 Message-ID: <13bfe4a4-193d-4e8e-a520-7e261b9d6131@linux.alibaba.com> Date: Sat, 16 Nov 2024 11:00:14 +0800 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 4/5] mm: shmem: add a kernel command line to change the default huge policy for tmpfs To: David Hildenbrand , Daniel Gomez , akpm@linux-foundation.org, hughd@google.com Cc: willy@infradead.org, wangkefeng.wang@huawei.com, 21cnbao@gmail.com, ryan.roberts@arm.com, ioworker0@gmail.com, linux-mm@kvack.org, linux-kernel@vger.kernel.org References: <64091a3d5a8c5edb0461fae203cfcf6f302a19ce.1731397290.git.baolin.wang@linux.alibaba.com> From: Baolin Wang In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 2129F140027 X-Stat-Signature: fqcpgimomjikq4e5x9ktawh3icpm1ng9 X-Rspam-User: X-Rspamd-Server: rspam05 X-HE-Tag: 1731725984-64764 X-HE-Meta: U2FsdGVkX19IJeCCxAP2Bn/y67YmCUbjSzwoV3mXmgAnlqIrOsoxQqNcOsisTWAeZsvVM8YH//+qvNsDkocTmLIwQaVRqSWVUGxnVeXkiXHYR3h90XM90boAelMDNDEgopT1K9mSNvpdmn9oQzsom1uRx5gNVK4PpfEvRFnhbafmUy/ZGyygKVUkclDPqwbB33NTYf5VcnWmHT4HWPUQruU+oGHPUQUewKDnYlRB4CQ1mhOOaalFN1X0GK59VJ5dngB6pTrNTIZUgHotWiDYSZ3v1JEjmOvFzzciZcmuAHQ1IPMdCgaWi77mftBueSzDrBLfNgl/LsIOMq0b3cFDxHvSh3C7Q9y1wF2JxIsbVAyhZQ3rL44tGeFIV3e26rNrHibsqhlMLnkf9og9erJJFtOL5aBka9ZKZgTT32PNuMHGz0mlxm90P5eguIPrLYi1tIlayUL6BDMhwT8n57w7hykJlgJVOmlTwMYACzK7RLuh8iTxDXRQKNpghH80tp5cPjNxblzVaFb8GX+GGFfHHsgl7hvcyx+DFDKRAaTVsNljbDo2V0HfbUYazeqCp+CXa3UGE4N+7edSfoaUuRruhEhu5Ysya7r9Azc/kge2Qe+aOO3E8A3WNT6EYglr0vAyQGNypOnoyz7e5aV7UACTUX8higi538t7sWAuzIToLvfHDD5wc41dM/Oj/NQrNSOCH6vTBkV4SKcINj6ehDE3jKoTkJ9THDwopk9jAYJboaG65dp+CJyaCpt8/ltU2PYHIXOvfOG4wbawDHCjNh2OaH42EsMXrBHrqVT7OvwwLdlZLM/DfdrMvsxOWqC+YtMfdwNFTyOLCZ6DVuhu0LPTitKpiDrcFOkFQ/o1IrPEyOBazBCKVJtJlFCjIaQzfel1nY6dhhaF7ccugHnu1zvL4/3z5rAztuGQ3JEcVBxKFVTn5JrKlOwtdGsyK3mPHMBmpZt/3Cq2zco3GqBeT4K 3SVzLc61 7IcRWKZMvskigxE0fwluztO7Myl9MELYSijIjuhJoW7687+EdV7Rfx990rhUmenBr5xdvdrHEdpzpn0GX7PG207t4I0NsUhOabZU2qX0jOZfc++Z0dYVdaB+whis4Qwaif3Y7NToHFcRSDG6tuBs8JuQw3mikMUV89Ab/ZLg8nCHiEOYbZ2JtAR3ZkfGErol/QzMm9bvLxGQg5KrlgD3S/lM8uOgXfXDIg3zzGl3awFVOOCxwg8QaqzKod3gT1He9v2fzIssqHFBFCj3j0nerqCec+6EgnuuuU0W4NCx3vfICzKsuZd68R3abY0JUTsA2p52XUfA95GNk9R4= 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/11/15 22:54, David Hildenbrand wrote: > On 15.11.24 15:02, Daniel Gomez wrote: >> On Tue Nov 12, 2024 at 8:45 AM CET, Baolin Wang wrote: >>> Now the tmpfs can allow to allocate any sized large folios, and the >>> default >>> huge policy is still 'never'. Thus adding a new command line to change >>> the default huge policy will be helpful to use the large folios for >>> tmpfs, >>> which is similar to the 'transparent_hugepage_shmem' cmdline for shmem. >> >> >> I think it would be good to include a summary of why tmpfs is not >> enabling large folios by default as the other fs. David has been >> pretty good at repeating the reasons over and over and it would be very >> valuable to have them included here. OK. I'd like to directly quote David's previous comments. So hope Andew can help include the updated commit message: ===== Now the tmpfs can allow to allocate any sized large folios, and the default huge policy is still prefered to be 'never'. Due to tmpfs not behaving like other file systems in some cases as previously explained by David[1]: " I think I raised this in the past, but tmpfs/shmem is just like any other file system .. except it sometimes really isn't and behaves much more like (swappable) anonymous memory. (or mlocked files) There are many systems out there that run without swap enabled, or with extremely minimal swap (IIRC until recently kubernetes was completely incompatible with swapping). Swap can even be disabled today for shmem using a mount option. That's a big difference to all other file systems where you are guaranteed to have backend storage where you can simply evict under memory pressure (might temporarily fail, of course). I *think* that's the reason why we have the "huge=" parameter that also controls the THP allocations during page faults (IOW possible memory over-allocation). Maybe also because it was a new feature, and we only had a single THP size. " Thus adding a new command line to change the default huge policy will be helpful to use the large folios for tmpfs, which is similar to the 'transparent_hugepage_shmem' cmdline for shmem. [1] https://lore.kernel.org/all/cbadd5fe-69d5-4c21-8eb8-3344ed36c721@redhat.com/ > Yes. We also discussed in v4 the idea of having a Kconfig option to just > change the default policy to "always". We could mention that here as well.