From: Daniel Gomez <da.gomez@kernel.org>
To: "Ville Syrjälä" <ville.syrjala@linux.intel.com>
Cc: Baolin Wang <baolin.wang@linux.alibaba.com>,
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 <eero.t.tamminen@intel.com>
Subject: Re: [REGRESSION] Re: [PATCH v3 3/6] mm: shmem: add large folio support for tmpfs
Date: Wed, 30 Apr 2025 15:24:03 +0200 [thread overview]
Message-ID: <cxwpgygobg6wleoeezbowjhmid4mdhptzheqask44ew37h2q24@kryzkecuobbp> (raw)
In-Reply-To: <aBIHYqzar5J8uxGO@intel.com>
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?
Even if these are enabled, the possible difference may be that before, i915 was
using PMD pages (THP) always and now mTHP will be used, unless the file size is
as big as the PMD page. I think the always mount option would also try to infer
the size to actually give a proper order folio according to that size. Baolin,
is that correct?
And Ville, can you confirm if what i915 needs is to enable PMD-size allocations
always?
next prev parent reply other threads:[~2025-04-30 13:24 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-11-28 7:40 [PATCH v3 0/6] Support large folios " Baolin Wang
2024-11-28 7:40 ` [PATCH v3 1/6] mm: factor out the order calculation into a new helper Baolin Wang
2024-11-28 7:40 ` [PATCH v3 2/6] mm: shmem: change shmem_huge_global_enabled() to return huge order bitmap Baolin Wang
2024-11-28 7:40 ` [PATCH v3 3/6] mm: shmem: add large folio support for tmpfs Baolin Wang
2025-04-29 17:44 ` [REGRESSION] " Ville Syrjälä
2025-04-30 6:32 ` Baolin Wang
2025-04-30 11:20 ` Ville Syrjälä
2025-04-30 13:24 ` Daniel Gomez [this message]
2025-05-02 1:02 ` Baolin Wang
2025-05-02 7:18 ` David Hildenbrand
2025-05-02 13:10 ` Daniel Gomez
2025-05-02 15:31 ` David Hildenbrand
2025-05-06 3:33 ` Baolin Wang
2025-05-06 14:36 ` David Hildenbrand
2024-11-28 7:40 ` [PATCH v3 4/6] mm: shmem: add a kernel command line to change the default huge policy " Baolin Wang
2024-11-28 7:40 ` [PATCH v3 5/6] docs: tmpfs: update the large folios policy for tmpfs and shmem Baolin Wang
2024-11-28 7:40 ` [PATCH v3 6/6] docs: tmpfs: drop 'fadvise()' from the documentation Baolin Wang
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=cxwpgygobg6wleoeezbowjhmid4mdhptzheqask44ew37h2q24@kryzkecuobbp \
--to=da.gomez@kernel.org \
--cc=21cnbao@gmail.com \
--cc=akpm@linux-foundation.org \
--cc=baolin.wang@linux.alibaba.com \
--cc=da.gomez@samsung.com \
--cc=david@redhat.com \
--cc=eero.t.tamminen@intel.com \
--cc=hughd@google.com \
--cc=intel-gfx@lists.freedesktop.org \
--cc=ioworker0@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=regressions@lists.linux.dev \
--cc=ryan.roberts@arm.com \
--cc=ville.syrjala@linux.intel.com \
--cc=wangkefeng.wang@huawei.com \
--cc=willy@infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox