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 2CE8FCEBF69 for ; Fri, 27 Sep 2024 02:36:57 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id B07806B00A7; Thu, 26 Sep 2024 22:36:56 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id A90566B00A8; Thu, 26 Sep 2024 22:36:56 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 930F86B00A9; Thu, 26 Sep 2024 22:36:56 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0012.hostedemail.com [216.40.44.12]) by kanga.kvack.org (Postfix) with ESMTP id 709296B00A7 for ; Thu, 26 Sep 2024 22:36:56 -0400 (EDT) Received: from smtpin25.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id 176271608DD for ; Fri, 27 Sep 2024 02:36:56 +0000 (UTC) X-FDA: 82608955632.25.72AC128 Received: from out30-110.freemail.mail.aliyun.com (out30-110.freemail.mail.aliyun.com [115.124.30.110]) by imf17.hostedemail.com (Postfix) with ESMTP id 6F71940008 for ; Fri, 27 Sep 2024 02:36:51 +0000 (UTC) Authentication-Results: imf17.hostedemail.com; dkim=pass header.d=linux.alibaba.com header.s=default header.b=ecW4kGMt; dmarc=pass (policy=none) header.from=linux.alibaba.com; spf=pass (imf17.hostedemail.com: domain of baolin.wang@linux.alibaba.com designates 115.124.30.110 as permitted sender) smtp.mailfrom=baolin.wang@linux.alibaba.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1727404576; a=rsa-sha256; cv=none; b=HcIwRjV/ouhfgccHiCJ7xXHiBrLQyZxNAwSFl5fal6MJlpxasPAE02I8ZnGnhCIiDOookY wKx07DrLkW1Z/ThVMqwgoj+h+7lOdRC/n88nXfOzjKMhdO/aG5sakeXh8hIVF2Ov7dWmK9 8zUuVvZ/ixbeo1qTZbcpuj88ufU92ls= ARC-Authentication-Results: i=1; imf17.hostedemail.com; dkim=pass header.d=linux.alibaba.com header.s=default header.b=ecW4kGMt; dmarc=pass (policy=none) header.from=linux.alibaba.com; spf=pass (imf17.hostedemail.com: domain of baolin.wang@linux.alibaba.com designates 115.124.30.110 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=1727404576; 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=3DirFBBLsGZoR5mffHo1eYqOeuH3dk7sCjq7ZC7LMd8=; b=cVo10WYyAFSJEsHaBNrW+NXlX9ESWfvxdIeaNYDYgygUjqvpo7yrRtoHvyVEItLNQ0kjS2 3KBgZCFfCJTpyLyNeEFpZsq7NXZEATGt7u8eoNqH8Y7JIN2L65zyInnrA9s8kDpXu0zRAJ 5Uh6yJ2P0Q8+HgAP7P5tWdXgt/H1Epo= DKIM-Signature:v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.alibaba.com; s=default; t=1727404602; h=Message-ID:Date:MIME-Version:Subject:To:From:Content-Type; bh=3DirFBBLsGZoR5mffHo1eYqOeuH3dk7sCjq7ZC7LMd8=; b=ecW4kGMtPu5068ABu5MuJEittEB8cp3VW1QKObG/ZR8X4+dNfm9GG3+VkjAFHwy5jo48Z3WIIZPFmSpVeBVqUTLhsGyU/cczYAsg9oz6nV5qdVQo/7W8mvPUIuACqfUnXVVjBFGNWgm2eXpz6wNSQ6m4eh1QgiIXzlXRAfMGhOE= Received: from 30.74.144.105(mailfrom:baolin.wang@linux.alibaba.com fp:SMTPD_---0WFooSAm_1727404600) by smtp.aliyun-inc.com; Fri, 27 Sep 2024 10:36:41 +0800 Message-ID: <300de9ce-7a3d-4495-a232-c7cb419289a5@linux.alibaba.com> Date: Fri, 27 Sep 2024 10:36:39 +0800 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [RFC PATCH v2 0/2] Support large folios for tmpfs To: Matthew Wilcox Cc: akpm@linux-foundation.org, hughd@google.com, david@redhat.com, wangkefeng.wang@huawei.com, 21cnbao@gmail.com, ryan.roberts@arm.com, ioworker0@gmail.com, da.gomez@samsung.com, linux-mm@kvack.org, linux-kernel@vger.kernel.org References: From: Baolin Wang In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Rspam-User: X-Rspamd-Queue-Id: 6F71940008 X-Rspamd-Server: rspam01 X-Stat-Signature: i3a7rpwmy1318gsq4tf8r55knutfmxng X-HE-Tag: 1727404611-480465 X-HE-Meta: U2FsdGVkX1+Osh0vopNcH8FIrsV/bwvKOHR/JeTR0AqQaWTI0rLIFUFGhWHMB7AgkjSmSs/j9ppNRogICkAASbenMzI3Z0TQjLrIiF3+KnzuCMr46HXb2CmOkhbSCr3esoxwmD9fT5ZAB72QyjlnWP9DbhvKvaxetc8oOK0cBBymKwIJKYCWlIkASgAw9uo3xABtLsfFzxpwz4O8FwUyki6WA5VWuW9XcNK+utec4rqaeBf7TiJ9k2JvVkEJXzvSrQK3Ktc0VTQtgqf9DaJJraozxf9RRMAhbuOsF2C7VbZkRnxE8KzNGXWY+sRCZ4+qHlvzt2KQSvLS9q2JYvF5xUEmKBSNP2AeqMX93q1uqfRvXPjjeqRjrK6LrcXSnZ86KyGB8OttbpnaF9AG0Qv5KmJoREPmSD2UxyDUB1CXm4eTntLZ2Rp2UvWFDBZ5kvJS6yz0RgmtPt4QbBAV/u0X4mfNUuTPJbbYmR2kRKTMuNOOlvChDxqC6t0j1PHZmSpr/t05d9QAYyG9eLqLvZQd01ikP/iWY0cCvE8jfu5Qp4L2hwHhgo4z6vOuzISQPPrZ6D91FeZor+q8+OQXROAXJM+xtDkU1Ls3zo91+VoT35dxpBL7ajTfCQomi09cOKtINhRWYN4k8Tw8xQZq02d9/HtfON2BPRHoUyZl5ViTO2rNf/9CICarn8J5kvPhkRxypBttrP9dRqI+GcjF7c+VABOjPqyVDZwG45PGLhHJlIhuntpcYhBorKehQEik32u/5y9ThiMkaDwGoUC0EiPepI8RXTNPN8reRbmCm8R5i4ASMUh8wcEFWAU4prKeOIV5XFByqTms4qnZygTNnih7DxcKXsKM0FcL29zI8BiozheR4l7X8sv/btYYxamgVJDcV83drZeaJuo6FqM3rfv/aEVEBm2sZFgd6aRjZv9FVq26SeRB+lLts9npGw241huJZUyV5Z4PTi6BsfP3K82 x7PPyYUl CXrQRGsKIZG7lryvsNAT2v+fE/O78e+osxEQWkGR+BO6vz+2+F04fxI/MagDgBRxZxmKat6KXFH8bsQ0Dm77vjM4C4Uq3LcFuZGIlnBW1/sUFCN9V2fJ/sT8tD7Tdnh2Z2fRDo//1kaSAjmk/ScKhVxe7ETMfzBDFsCZ9dxOLnTse2QukFlFCVTgunvLM4bQNiOLEgm8QJVrsJr1HYVtfhuNyuUrZw2/XqRCOytt2oBqoG2pkVDTbMujVX3XdjPMjId4t 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/9/26 20:20, Matthew Wilcox wrote: > On Thu, Sep 26, 2024 at 04:27:25PM +0800, Baolin Wang wrote: >> This RFC patch series attempts to support large folios for tmpfs. The first >> patch is based on Daniel's previous patches in [1], mainly using the length >> in the write and fallocate paths to get a highest order hint for large >> order allocation. The last patch adds mTHP filter control for tmpfs if mTHP >> is set for the following reasons: >> >> 1. Maintain backward compatibility for the control interface. Tmpfs already >> has a global 'huge=' mount option and '/sys/kernel/mm/transparent_hugepage/shmem_enabled' >> interface to control large order allocations. mTHP extends this capability to a >> per-size basis while maintaining good interface compatibility. > > ... it's confusing as hell to anyone who tries to understand it and > you've made it more complicated. Well done. > >> 2. For the large order allocation of writable mmap() faults in tmpfs, we need >> something like the mTHP interfaces to control large orders, as well as ensuring >> consistent interfaces with shmem. > > tmpfs and shmem do NOT need to be consistent! I don't know why anyone > thinks this is a goal. tmpfs should be consistent with OTHER FILE > SYSTEMS. shmem should do the right thing for the shared anon use case. > >> 3. Ryan pointed out that large order allocations based on write length could >> lead to memory fragmentation issue. Just quoting Ryan's comment [2]: >> "And it's possible (likely even, in my opinion) that allocating lots of different >> folio sizes will exacerbate memory fragmentation, leading to more order-0 >> fallbacks, which would hurt the overall system performance in the long run, vs >> restricting to a couple of folio sizes." > > I disagree with this. It's a buddy allocator; it's resistant to this > kind of fragmentation. Fine. Thanks for sharing your opinion. So far, I can drop patch 2 to stop adding mTHP interfaces for tmpfs.