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 >
