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 1A5A9C369D9 for ; Wed, 30 Apr 2025 06:32:49 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 2E60A6B00B9; Wed, 30 Apr 2025 02:32:47 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 26E226B00BC; Wed, 30 Apr 2025 02:32:47 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 0E75F6B00D4; Wed, 30 Apr 2025 02:32:47 -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 D071C6B00B9 for ; Wed, 30 Apr 2025 02:32:46 -0400 (EDT) Received: from smtpin12.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id F1A4FBED30 for ; Wed, 30 Apr 2025 06:32:47 +0000 (UTC) X-FDA: 83389741974.12.67AFAC0 Received: from out30-100.freemail.mail.aliyun.com (out30-100.freemail.mail.aliyun.com [115.124.30.100]) by imf22.hostedemail.com (Postfix) with ESMTP id 05087C000D for ; Wed, 30 Apr 2025 06:32:44 +0000 (UTC) Authentication-Results: imf22.hostedemail.com; dkim=pass header.d=linux.alibaba.com header.s=default header.b=KwfV2l9S; dmarc=pass (policy=none) header.from=linux.alibaba.com; spf=pass (imf22.hostedemail.com: domain of baolin.wang@linux.alibaba.com designates 115.124.30.100 as permitted sender) smtp.mailfrom=baolin.wang@linux.alibaba.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1745994766; a=rsa-sha256; cv=none; b=3+TLv+wOUi1P4D0wLHa/FZB/4+LnTvluDbojBXJMg1jOWmL9gJp7tOdxB10R7r09CLuzxb it3qen+YzrKU9ZS7gavK15LAsCdUl6SDdh4s+RrTInk2y03kX8t9qb+h4e1ErzB4jojEPS eKNLWaiFrusNMOdluQuDrVMG0dUJ7Cc= ARC-Authentication-Results: i=1; imf22.hostedemail.com; dkim=pass header.d=linux.alibaba.com header.s=default header.b=KwfV2l9S; dmarc=pass (policy=none) header.from=linux.alibaba.com; spf=pass (imf22.hostedemail.com: domain of baolin.wang@linux.alibaba.com designates 115.124.30.100 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=1745994766; 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=+3dOwVuJc4MtjszVeCAWClZNbK6KcQVywAp2ZsO4nNg=; b=GfZnx1w5orFJki+W63mE2YY/Q8DGyA/3FCJ12ivVaHqvmqZTX1NiAkKtKwFC60LkxJLZw3 8WSNgaIYjwRxBEK+oFcMUv2VK4Mrtz5g017SvfKlmsOJQk72+JzrZqeoxEhdHEuCnWTmHV fiMHQP1kOUBjNiL7LRBW75jBpebSXGI= DKIM-Signature:v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.alibaba.com; s=default; t=1745994761; h=Message-ID:Date:MIME-Version:Subject:To:From:Content-Type; bh=+3dOwVuJc4MtjszVeCAWClZNbK6KcQVywAp2ZsO4nNg=; b=KwfV2l9SpeOZuvqwC6+Y5N0S3YZAwdRR30cNboucPdDwAvj9Y1l2/igOZVvG3XN0Ncq0EJshar2n+WZrh7lQPNeK5Cnsbu0wjaneg35lzLDaDQa5+3hJTMhX/bST8U0388QLubo1rv/YzKQ32IMljU3NNXkJohJvBD73OYt+lfQ= Received: from 30.74.146.9(mailfrom:baolin.wang@linux.alibaba.com fp:SMTPD_---0WYnVO33_1745994759 cluster:ay36) by smtp.aliyun-inc.com; Wed, 30 Apr 2025 14:32:40 +0800 Message-ID: Date: Wed, 30 Apr 2025 14:32:39 +0800 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [REGRESSION] Re: [PATCH v3 3/6] mm: shmem: add large folio support for tmpfs To: =?UTF-8?B?VmlsbGUgU3lyasOkbMOk?= Cc: akpm@linux-foundation.org, hughd@google.com, willy@infradead.org, 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, regressions@lists.linux.dev, intel-gfx@lists.freedesktop.org, Eero Tamminen References: <035bf55fbdebeff65f5cb2cdb9907b7d632c3228.1732779148.git.baolin.wang@linux.alibaba.com> From: Baolin Wang In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Rspamd-Server: rspam03 X-Rspamd-Queue-Id: 05087C000D X-Stat-Signature: 6tgmcwrq11cjtx1tsjem5hcjncugnmce X-Rspam-User: X-HE-Tag: 1745994764-222861 X-HE-Meta: U2FsdGVkX1+L21uLjkc1iPS6vmWTc2dZWmhy9I/kmcTC1adO0BlZca509FYP2Tp4DT/DBGdpvw+ETBuJWmb8LmmgCQvoA729AhIKqjhI4+9whRnOAh9zezDLlP6MvwsoJlHg5iM5KweldD6IVSt5aQ9jbh0qpxAobhO+bgtyArD1lr/ONkoS7uKQzghaz5mGB1rJ2yZ5axj1NJnYBX6MmC4t/GP7t5Jicb2D9B8LIGAOLunoIXJtUgRie0wrPYi3R7Tk4p7jkQzyvSnvfAo2xkuJ4rYuzZCQdvVdl0fE6bSHjwv2wnySAkV3km2WH0HagoY2JegLBjg3gVarav1gJi7LhSrgE9WY1WXeCZmyx3z3gaXXC1Bg5VuYjOP+gLle5YUCAsZqXGlOr40Thh6NyL56Qj3hPc1uxUvfc3rpH5xVz9x0ilC2RVXvTIGyAj/0xJnUptrGl2DLcGtY+g0iPjfxXOgE7zZyuIEJcjKmybb4ea1Xzpfl3i0Mn/9Y1VDAQQKYVjUzzFfODklC1eoFizXlLrbMsasLi9BvwR4rbzhLZ1NX5lu0URte5avFpaC4m1A/r7LcMVNMunyV5yc//NCINADrrSxnCpmrt+DmWB1CXA6VfIOcEWVRhoi60pPyTOb+rQ4b+q7DDT0EuwCyy+IQCbrBQafqmBfE/K00w41a/iyeaouIBAcUvPkg2OWf2K3janaCnka6UMdxZmGJdPSL6XoftBsAmxWQCUkvoD+Aq/z/uEp8M0UqwsSmorKcdP712iiI/CdVtUIObmSVrlWaxRvVUw/mXeB9aIXG1Y9k1jgNmOQld6ws5OEU8+gwrFZlNCg+1MkrXWDYWBehZ5Q39i+TXTm5W13/FC3mFiFJpO/fdEiRERjSrvl5Kx6PXcNzt8oaPOjIAosFR6GmCJ/Z72e2fP9Az2snJD6RPSKfC0j6O41TU5gQY8+0zpbKAyUNXpCHImeJdvZR8Y8 Q1QMRS27 9F3QUqwSiWd+bsbULJG9Ww/tHKl6nWnThW/9X3x+yb3e/VPUuXntNLNro3z9UpWN79URLwRuR9hJH6e9DM3yWey4XtMFOvTc7BeJmxrCoSaK7JxU1SlIjbUcryWuYOL6e+HUrQi1BHsLQ8XtzAMCQTHeH9SBI3CS+xjDO6b65exNQiLlRrcgB5c9PVbOz7G5lwSxlTSkyfxkK7+pMBR6lJYR03qGGuH/1SvY8zga181QvX1AZPGbmmeOfeJxatIKmXOMeQCZlxpmqgp7Iz5uc5s9ovMr+wUs6vYAHcfmnQqyWzdboKH5MX4Z3aYplifEUkP6O8kLe2UY4LMU= 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: Hi, On 2025/4/30 01:44, Ville Syrjälä wrote: > On Thu, Nov 28, 2024 at 03:40:41PM +0800, Baolin Wang wrote: >> Add large folio support for tmpfs write and fallocate paths matching the >> same high order preference mechanism used in the iomap buffered IO path >> as used in __filemap_get_folio(). >> >> Add shmem_mapping_size_orders() to get a hint for the orders of the folio >> based on the file size which takes care of the mapping requirements. >> >> Traditionally, tmpfs only supported PMD-sized large folios. However nowadays >> with other file systems supporting any sized large folios, and extending >> anonymous to support mTHP, we should not restrict tmpfs to allocating only >> PMD-sized large folios, making it more special. Instead, we should allow >> tmpfs can allocate any sized large folios. >> >> Considering that tmpfs already has the 'huge=' option to control the PMD-sized >> large folios allocation, we can extend the 'huge=' option to allow any sized >> large folios. The semantics of the 'huge=' mount option are: >> >> huge=never: no any sized large folios >> huge=always: any sized large folios >> huge=within_size: like 'always' but respect the i_size >> huge=advise: like 'always' if requested with madvise() >> >> Note: for tmpfs mmap() faults, due to the lack of a write size hint, still >> allocate the PMD-sized huge folios if huge=always/within_size/advise is set. >> >> Moreover, the 'deny' and 'force' testing options controlled by >> '/sys/kernel/mm/transparent_hugepage/shmem_enabled', still retain the same >> semantics. The 'deny' can disable any sized large folios for tmpfs, while >> the 'force' can enable PMD sized large folios for tmpfs. >> >> Co-developed-by: Daniel Gomez >> Signed-off-by: Daniel Gomez >> Signed-off-by: Baolin Wang > > Hi, > > This causes a huge regression in Intel iGPU texturing performance. Unfortunately, I don't have such platform to test it. > > I haven't had time to look at this in detail, but presumably the > problem is that we're no longer getting huge pages from our > private tmpfs mount (done in i915_gemfs_init()). IIUC, the i915 driver still limits the maximum write size to PAGE_SIZE in the shmem_pwrite(), which prevents tmpfs from allocating large folios. As mentioned in the comments below, tmpfs like other file systems that support large folios, will allow getting a highest order hint based on the size of the write and fallocate paths, and then will attempt each allowable huge order. Therefore, I think the shmem_pwrite() function should be changed to remove the limitation that the write size cannot exceed PAGE_SIZE. Something like the following code (untested): diff --git a/drivers/gpu/drm/i915/gem/i915_gem_shmem.c b/drivers/gpu/drm/i915/gem/i915_gem_shmem.c index ae3343c81a64..97eefb73c5d2 100644 --- a/drivers/gpu/drm/i915/gem/i915_gem_shmem.c +++ b/drivers/gpu/drm/i915/gem/i915_gem_shmem.c @@ -420,6 +420,7 @@ shmem_pwrite(struct drm_i915_gem_object *obj, struct address_space *mapping = obj->base.filp->f_mapping; const struct address_space_operations *aops = mapping->a_ops; char __user *user_data = u64_to_user_ptr(arg->data_ptr); + size_t chunk = mapping_max_folio_size(mapping); u64 remain; loff_t pos; unsigned int pg; @@ -463,10 +464,10 @@ shmem_pwrite(struct drm_i915_gem_object *obj, void *data, *vaddr; int err; char __maybe_unused c; + size_t offset; - len = PAGE_SIZE - pg; - if (len > remain) - len = remain; + offset = pos & (chunk - 1); + len = min(chunk - offset, remain); /* Prefault the user page to reduce potential recursion */ err = __get_user(c, user_data);