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 914DFC369CE for ; Thu, 26 Sep 2024 12:20:33 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 22DD16B0092; Thu, 26 Sep 2024 08:20:33 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 1DDB46B0093; Thu, 26 Sep 2024 08:20:33 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 0A5EC6B0095; Thu, 26 Sep 2024 08:20:33 -0400 (EDT) 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 DF9A46B0092 for ; Thu, 26 Sep 2024 08:20:32 -0400 (EDT) Received: from smtpin01.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id 53ECB160953 for ; Thu, 26 Sep 2024 12:20:32 +0000 (UTC) X-FDA: 82606797504.01.22A4E88 Received: from casper.infradead.org (casper.infradead.org [90.155.50.34]) by imf20.hostedemail.com (Postfix) with ESMTP id ADE461C000E for ; Thu, 26 Sep 2024 12:20:30 +0000 (UTC) Authentication-Results: imf20.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=u+iZ8zT+; dmarc=none; spf=none (imf20.hostedemail.com: domain of willy@infradead.org has no SPF policy when checking 90.155.50.34) smtp.mailfrom=willy@infradead.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1727353132; a=rsa-sha256; cv=none; b=Z/Tz2+ta8i9TAhnmTyGXJt1CdLZUATJg/d3OJ0DOqDT/auLiThCAVPGAXIX6QFKrXDUl72 zgyct1CiBTzAvUTUu1xzr9qFkehXtXpYjB58NXjVzdW9cVRPeGqozN9Bw0ZDQhb1a1aSq2 f1KUhN5G5yQE6ruaAGNVu4nFaP7Z8/Q= ARC-Authentication-Results: i=1; imf20.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=u+iZ8zT+; dmarc=none; spf=none (imf20.hostedemail.com: domain of willy@infradead.org has no SPF policy when checking 90.155.50.34) smtp.mailfrom=willy@infradead.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1727353132; 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: in-reply-to:in-reply-to:references:references:dkim-signature; bh=8ZdSVGWk34/kGEegWA4c5xkhFSAJiSLDxkV6IKWrllY=; b=0brd93vRnS4clDAepfCBgVX14C5R/Lb3kmNBSatloNnjOnWGMbWP+2oH7F3lPS6mvH+kzR pvjEpGMb3ajMZYvcvZ8zPuwwT80Lk3G9ho+mzz1fs6WvWl1C6ghIAvEbGu84iBhHb3wHJF GmWgTMUweuTlR2Mbw/4pMpCZyKC5iVs= DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=casper.20170209; h=In-Reply-To:Content-Type:MIME-Version: References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description; bh=8ZdSVGWk34/kGEegWA4c5xkhFSAJiSLDxkV6IKWrllY=; b=u+iZ8zT+9Zyie6sCCPjCzLaRj0 VRhyFx5h9SQA+9wjWtEDJBG+upmmVL7KlMqwuvdvCqwvMOr2eoKuGjkeb3sBK8HvqRRSOhh/fA2Yn TIIWsytqgykm1OftMxsvmRVta29feFzat9RySex23WCvHJHd50qNILTuGBXuJ/jliYe1r47N1Mugt SZh5TtkTzAZ5PjUTuhTCctDlxf2rOXFi3coByKMgDMIVq+hD+2BJrp5YznBDh15c8LH2uCq8cXPJ1 xsDOAkYVJYS4DUH/wWVHNLHax0x5TA2CQw8E1B5/UaaVuEzsoL3yZxuIjQjE/fwU06GTAJmP0Pr0O M4hitnWA==; Received: from willy by casper.infradead.org with local (Exim 4.98 #2 (Red Hat Linux)) id 1stnTt-00000006bEF-0NbM; Thu, 26 Sep 2024 12:20:25 +0000 Date: Thu, 26 Sep 2024 13:20:24 +0100 From: Matthew Wilcox To: Baolin Wang 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 Subject: Re: [RFC PATCH v2 0/2] Support large folios for tmpfs Message-ID: References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspamd-Server: rspam12 X-Rspamd-Queue-Id: ADE461C000E X-Stat-Signature: 69iwxz78sfd9jsyg3w7t9m5oh6shhjof X-Rspam-User: X-HE-Tag: 1727353230-845890 X-HE-Meta: U2FsdGVkX1+UvwujbxCiNnfpY/ZUUv6WhCZcXBkCQ6CW5WHf6ci2LCw4IGPJNDQvY9uy1ajgmHivfZjlQKRRNcr/5gC/VdFrIhxdTdJJkqE0E6BniiD5IocjpA8DEDNFVnfzxe6HJhpc/aF4FTTNTs7ssKu2htCjRIWp7+4aNWsZzNTqO9kj0lFP3vWvrUQNZj+yXFnlT/XMrFL7uIsXEYu+j6N6Sj33LmLWpu5AahMWHzo6v1g/LnRNmw3w0RAMW40zhFyrqryokbVTR0u3vwPSGX7dCoN3Fw5OjsaYvO12Xk+3PVJV2WxAZ8m/UhmnouCNPWMJK2cfr1e3VrASjDsTNT/UJyI7GGIm5zgNJ3SNuhaGKNQ1HHpkvSAcCnVfQWSIWHoa75AeKJE9Ll5WpY6xtIA7aj6s6lYYzdHwXOygRG9+JI8tqgqG7LeU6nHdoj9eW6HaHRqrvBnJbFqx1vwGkKLCp6rWRnbRL7qlaVGBO0vaHTjnXz9qek7QrTVgN75pgqp45fPGEkRWY/WFWsukPGaNClHwKqbg1e/WvrOOqq0pmj+Kc5Xm4E8YmLmthvkE/0i9RyaI9qiHyFPWBYMDn9q+NJC+2cbN0lFn347Cw2fO34I9KOtYP2K0w64q2Ozm7GF6KrN76x4MBZFVjnxJxj0SwMYLQusATcWXnWhHVtfmcjfO5xwj/jCLINZ8gaM8ZlNgmE3Z0pDOon7AMfxdPg1o2nb6/sZ7e5V07tSjn0zaabK8b9Q3A4IvFQ3a1BLfGpK+t8gqP8AxMBDrLZy//vH+PmiElQZnNNL/BPJ3ONCwhtziqxz8+/RRBWVLv7UEKO1Z/9/Y1xLbjZmzWnDx12M5ABThSPIVcy7LEvTENRG06kMDGH9rXOjapx5y0dVp2NKo00o8ebW66KJ/vkGuM8Dt9jKuJla/ynrwSqNjIeELEwiALJR6qhVGLJv1+zVn+nrAgKO3gMOKUr/ eLBzLRFg 01AxouMMgWW8tm5wbauhrIPjJKySyb3H96HR43uCbU1mbMikEADBbGyzVORSnfD6i5xFzTwX8LveCd0itza4OavcT3lx8a106IVVGeV2qQk4xtBlUh1+cH3vD/7nKqYBpWXY7CZpoJVpvbKPSaVpkTmN/4R+H2pdDKyVwpfCPeICujoSHsj9RjI5phFo9lQv5ZZwxZKBAiJowCffEI7Jv2tm38CMKNl0m4Q1I13vKF6Kri64= 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 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.