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 8E90DC3ABA3 for ; Fri, 2 May 2025 13:10:08 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 7497D6B0088; Fri, 2 May 2025 09:10:07 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 6FA526B008C; Fri, 2 May 2025 09:10:07 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 5C0A56B0092; Fri, 2 May 2025 09:10:07 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id 3D4336B0088 for ; Fri, 2 May 2025 09:10:07 -0400 (EDT) Received: from smtpin29.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id E019D1A193A for ; Fri, 2 May 2025 13:10:06 +0000 (UTC) X-FDA: 83398000812.29.0EE718A Received: from tor.source.kernel.org (tor.source.kernel.org [172.105.4.254]) by imf24.hostedemail.com (Postfix) with ESMTP id 1F4EC180007 for ; Fri, 2 May 2025 13:10:04 +0000 (UTC) Authentication-Results: imf24.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=LQoZ5ISV; dmarc=pass (policy=quarantine) header.from=kernel.org; spf=pass (imf24.hostedemail.com: domain of da.gomez@kernel.org designates 172.105.4.254 as permitted sender) smtp.mailfrom=da.gomez@kernel.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1746191405; a=rsa-sha256; cv=none; b=nsy6FbzwSn81b6gvFvVYLR4wQLkHEjlF8F7aVjG9mhlxqCP+jwWEE5bQFY1F1Q6I/HRjUE yvs2q0shFn3Rp6gSdQp47gGRl42ReN+a8rqICff6XV66Kpc7OS+P1fE5fHtq+vh0h07hyH AI46f4XiL7mWtWQ/LwQlm3Y5410tbDI= ARC-Authentication-Results: i=1; imf24.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=LQoZ5ISV; dmarc=pass (policy=quarantine) header.from=kernel.org; spf=pass (imf24.hostedemail.com: domain of da.gomez@kernel.org designates 172.105.4.254 as permitted sender) smtp.mailfrom=da.gomez@kernel.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1746191405; 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=wq3XBMkP+notXL5cFRaG41JOWCKD9Yp0KbYuNOxIUqU=; b=ik/o1WGMhzyMfeDLgcX+I2YbxiLzEP7t2793wY4CWbv9C04eG8PSE+UcWFQ0VnYWEK/90W 73xa5Ts/JsJtTkNiL83vaE9hb6X3XqfKG8WtvpDSluD2/rdliCL0yDz9dtL7bhBmLSdoYM IEkhG85rBwh0roTaMyXAjFvVEi01vaA= Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by tor.source.kernel.org (Postfix) with ESMTP id BA0F460007; Fri, 2 May 2025 13:09:35 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 8E6A0C4CEE4; Fri, 2 May 2025 13:10:03 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1746191404; bh=kELBzKdw0K3iVq9hQpcya/QBSYuiSk6p2J8adsr5ebY=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=LQoZ5ISVeAs4AbTlVVfvO2T392qjC8q/xmycLZHfgbRVJYYgaOO4sK9udVkpmjTd/ YRdP6dkDAyZ2jq8JgBo02uztmIVBd+oO50fDBYv3I8tu1g83MRFlFbX+aiDSbY2RW2 VRjXe6h0hmsqaiJbs2zHHcfEOQ/iBBJf1KYnyHqO/TNjcEiiInFaVJxdWr7bDVINyl G4pEaPWmF68XlxVdo1zdrXnbQ2Iv/VAU047ncNyBOKZF2oD451TTzn2sZsXO41ErNP pXWYCp9yad/xhJyEel25GNXQykgdh70EWOMNgO1GHDSWaxBUvh7fUP72jgfFgVpXdz AlVly+PUwRyTw== Date: Fri, 2 May 2025 15:10:01 +0200 From: Daniel Gomez To: David Hildenbrand , Baolin Wang Cc: Ville =?utf-8?B?U3lyasOkbMOk?= , akpm@linux-foundation.org, hughd@google.com, willy@infradead.org, 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 Subject: Re: [REGRESSION] Re: [PATCH v3 3/6] mm: shmem: add large folio support for tmpfs Message-ID: References: <035bf55fbdebeff65f5cb2cdb9907b7d632c3228.1732779148.git.baolin.wang@linux.alibaba.com> <57dc4929-268b-4f3f-a0f8-43d6ec85974f@linux.alibaba.com> <72978e3a-ee67-47d4-b06d-e911bc5d57ff@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <72978e3a-ee67-47d4-b06d-e911bc5d57ff@redhat.com> X-Rspam-User: X-Rspamd-Queue-Id: 1F4EC180007 X-Rspamd-Server: rspam04 X-Stat-Signature: byiktndwszkzte9hmzo3aqcd64kwaqw7 X-HE-Tag: 1746191404-94584 X-HE-Meta: U2FsdGVkX1+yMeM7d9waIynf6o+Fnyp9bw96jkqC6BjK/C7S40hyrqLA4kJprokzKjGxqPsflCQ8nUb2OaH1xMXHk/shJYPtf83lQBJoY5aQM0mDvQw3r82sbxw1ALChqb0dC4N7fuBKko0Zru7qyyR/TOWewO0g78yRgY7eJGl/NEs2mMhEBkDIfqMjszNQELf+PUeTh3fp3gDRVBS9ZCtiwylORHOsuBDv/y1YZt1CrvYNOqMNfYsFBKtQ+ykRJi/lWK41Y0K3l6MvACVtkpASqyqNa3oxG1wptf3bFz2X88cbd+JzF+qXePnWhWW81PuacE9BAazohzlzOOkWYoz/ov25mWXu4d3Vf0TVIf/4BfoHcV/K2lQE4u2VwxoIIoQ38iwYC8EtJlCAekoYIYjmjbHWf6KO4cQ0Y7HQVjlnFbad/rxMYG9Ayy8lnujxAlgdhlhvyZaomBr9H0brktCG2TytG6mj7FQHSGGJVYE0wJOAfhEgMGNvzbiV8j390AWofwQomAzY+hwjl2ZJpaRrCDeHFHVBrXlDeBrOlhT5wy4LdUnztXEexxD//hu9oIIVZivSKhwYgHy+CXNoA04/DS3zGXXRIjaAwVKk+0nVBMvmWHx9Zze1kzr9FPiFSbJBAnlrSoiQRc47tejo9Ju5Wld1iOfzj+3BZ7Mh+SU35zgBazbmhjBaJSeaL4gIiirmwlwm6AZS8YM5rrzuYQDKE3wyTrHWNK60gq151uNhVfMAvnqHV8aVo1jTJIyVVSWye6b2w7ZePpx9yTlOXNfZ9piLXbf59yWxNQj7tufjHjHFWBad0d2I/0bsAEpCVTVU+zmIJUu5Id/yL+dUCNUf64sRFImbLvjvoLIt2HJIlxwHWOxlgF6EHfxV92G+U1Bdcsa9RdyDVE8/nb1pLWn64QO0GbA0oWSYgTaAQwKEexYTIEDfa9LlLv6vIiHiN946pBCKPO7PqxdgugN 3/vxIHwy OUdQMCFToyzho45hevsL2b2hhJWUr4ldl4qnrFjQo3Y8/g5xDDWDaZGIaKG2TQFdq93cnx1YuBbuyuMXlOcpt257plhWuGSx+9PaW8vDs36TEBBKV5LgvINWHBOdIZIlLNbgBWC/6mbly9AeVnRbyPORx1QbItktn9YdbxdX7xAk5pbKojDGQJL7jyiZO+YHUtPPbRXieF4KUWKTF+MqDE57jxDd1PoNyXottiSwXO1l35kNaIrxuBJVcSatZeI4bSL68GDYMRM86pFx2C3EOKD6WQA== 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 Fri, May 02, 2025 at 09:18:41AM +0100, David Hildenbrand wrote: > On 02.05.25 03:02, Baolin Wang wrote: > > > > > > On 2025/4/30 21:24, Daniel Gomez wrote: > > > On Wed, Apr 30, 2025 at 02:20:02PM +0100, Ville Syrjälä wrote: > > > > On Wed, Apr 30, 2025 at 02:32:39PM +0800, Baolin Wang wrote: > > > > > On 2025/4/30 01:44, Ville Syrjälä wrote: > > > > > > On Thu, Nov 28, 2024 at 03:40:41PM +0800, Baolin Wang wrote: > > > > > > 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(), > > > > > > > > pwrite is just one random way to write to objects, and probably > > > > not something that's even used by current Mesa. > > > > > > > > > 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. > > > > > > To enable mTHP on tmpfs, the necessary knobs must first be enabled in sysfs > > > as they are not enabled by default IIRC (only THP, PMD level). Ville, I > > > see i915_gemfs the huge=within_size mount option is passed. Can you confirm > > > if /sys/kernel/mm/transparent_hugepage/hugepages-*/enabled are also marked as > > > 'always' when the regression is found? > > > > The tmpfs mount will not be controlled by > > '/sys/kernel/mm/transparent_hugepage/hugepages-*Kb/enabled' (except for > > the debugging options 'deny' and 'force'). > > Right, IIRC as requested by Willy, it should behave like other FSes where > there is no control over the folio size to be used. Thanks for reminding me. I forgot we finally changed it. Could the performance drop be due to the driver no longer using PMD-level pages? I also recall a performance drop when using order-8 and order-9 folios in tmpfs with the initial per-block implementation. Baolin, did you experience anything similar in the final implementation? These were my numbers: | Block Size (bs) | Linux Kernel v6.9 (GiB/s) | tmpfs with Large Folios v6.9 (GiB/s) | | 4k | 20.4 | 20.5 | | 8k | 34.3 | 34.3 | | 16k | 52.9 | 52.2 | | 32k | 70.2 | 76.9 | | 64k | 73.9 | 92.5 | | 128k | 76.7 | 101 | | 256k | 80.5 | 114 | | 512k | 80.3 | 132 | | 1M | 78.5 | 75.2 | | 2M | 65.7 | 47.1 | > > -- > Cheers, > > David / dhildenb >