All of lore.kernel.org
 help / color / mirror / Atom feed
From: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
To: Christoph Hellwig <hch@lst.de>, Matthew Wilcox <willy@infradead.org>
Cc: Hugh Dickins <hughd@google.com>,
	Chandan Babu R <chandan.babu@oracle.com>,
	"Darrick J . Wong" <djwong@kernel.org>,
	Andrew Morton <akpm@linux-foundation.org>,
	David Howells <dhowells@redhat.com>,
	Jarkko Sakkinen <jarkko@kernel.org>,
	Dave Hansen <dave.hansen@linux.intel.com>,
	Maarten Lankhorst <maarten.lankhorst@linux.intel.com>,
	Maxime Ripard <mripard@kernel.org>,
	Thomas Zimmermann <tzimmermann@suse.de>,
	David Airlie <airlied@gmail.com>, Daniel Vetter <daniel@ffwll.ch>,
	Christian Koenig <christian.koenig@amd.com>,
	Huang Rui <ray.huang@amd.com>,
	Jani Nikula <jani.nikula@linux.intel.com>,
	Rodrigo Vivi <rodrigo.vivi@intel.com>,
	Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>,
	intel-gfx@lists.freedesktop.org, dri-devel@lists.freedesktop.org,
	x86@kernel.org, linux-sgx@vger.kernel.org, linux-mm@kvack.org,
	linux-fsdevel@vger.kernel.org, keyrings@vger.kernel.org
Subject: Re: disable large folios for shmem file used by xfs xfile
Date: Wed, 10 Jan 2024 17:28:22 +0200	[thread overview]
Message-ID: <170490050245.164862.16261803493864298341@jlahtine-mobl.ger.corp.intel.com> (raw)
In-Reply-To: <170490002493.164187.5401160425746227111@jlahtine-mobl.ger.corp.intel.com>

Quoting Joonas Lahtinen (2024-01-10 17:20:24)
> Quoting Matthew Wilcox (2024-01-10 14:37:18)
> > On Wed, Jan 10, 2024 at 10:21:07AM +0100, Christoph Hellwig wrote:
> > > Hi all,
> > > 
> > > Darrick reported that the fairly new XFS xfile code blows up when force
> > > enabling large folio for shmem.  This series fixes this quickly by disabling
> > > large folios for this particular shmem file for now until it can be fixed
> > > properly, which will be a lot more invasive.
> > > 
> > > I've added most of you to the CC list as I suspect most other users of
> > > shmem_file_setup and friends will have similar issues.
> > 
> > The graphics users _want_ to use large folios.  I'm pretty sure they've
> > been tested with this.
> 
> Correct. We've done quite a bit of optimization in userspace and
> enabling in kernel to take advantage of page sizes of 2M and beyond.
> 
> However we specifically pass "huge=within_size" to vfs_kern_mount when
> creating a private mount of tmpfs for the purpose of i915 created
> allocations.
> 
> Older hardware also had some address hashing bugs where 2M aligned
> memory caused a lot of collisions in TLB so we don't enable it always.
> 
> You can see drivers/gpu/drm/i915/gem/i915_gemfs.c function
> i915_gemfs_init for details and references.
> 
> So in short, functionality wise we should be fine either default
> for using 2M pages or not. If they become the default, we'd probably
> want an option that would still be able to prevent them for performance
> regression reasons on older hardware.

To maybe write out my concern better:

Is there plan to enable huge pages by default in shmem?

If not I guess we should be pretty good with the way current code is, force
enabling them just might bring out some performance, so we might want to add
a warning for that.

If there is, then we'll probably want to in sync with those default changes
apply a similar call to block them on older HW.

Regards, Joonas

> 
> Regards, Joonas
> 
> > It's just XFS that didn't know about this
> > feature of shmem.

WARNING: multiple messages have this Message-ID (diff)
From: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
To: Christoph Hellwig <hch@lst.de>, Matthew Wilcox <willy@infradead.org>
Cc: "Darrick J . Wong" <djwong@kernel.org>,
	Dave Hansen <dave.hansen@linux.intel.com>,
	dri-devel@lists.freedesktop.org,
	David Howells <dhowells@redhat.com>,
	linux-mm@kvack.org, Huang Rui <ray.huang@amd.com>,
	x86@kernel.org, Hugh Dickins <hughd@google.com>,
	Thomas Zimmermann <tzimmermann@suse.de>,
	intel-gfx@lists.freedesktop.org,
	Maxime Ripard <mripard@kernel.org>,
	Rodrigo Vivi <rodrigo.vivi@intel.com>,
	linux-sgx@vger.kernel.org,
	Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>,
	Jarkko Sakkinen <jarkko@kernel.org>,
	keyrings@vger.kernel.org, linux-fsdevel@vger.kernel.org,
	Andrew Morton <akpm@linux-foundation.org>,
	Christian Koenig <christian.koenig@amd.com>,
	Chandan Babu R <chandan.babu@oracle.com>
Subject: Re: disable large folios for shmem file used by xfs xfile
Date: Wed, 10 Jan 2024 17:28:22 +0200	[thread overview]
Message-ID: <170490050245.164862.16261803493864298341@jlahtine-mobl.ger.corp.intel.com> (raw)
In-Reply-To: <170490002493.164187.5401160425746227111@jlahtine-mobl.ger.corp.intel.com>

Quoting Joonas Lahtinen (2024-01-10 17:20:24)
> Quoting Matthew Wilcox (2024-01-10 14:37:18)
> > On Wed, Jan 10, 2024 at 10:21:07AM +0100, Christoph Hellwig wrote:
> > > Hi all,
> > > 
> > > Darrick reported that the fairly new XFS xfile code blows up when force
> > > enabling large folio for shmem.  This series fixes this quickly by disabling
> > > large folios for this particular shmem file for now until it can be fixed
> > > properly, which will be a lot more invasive.
> > > 
> > > I've added most of you to the CC list as I suspect most other users of
> > > shmem_file_setup and friends will have similar issues.
> > 
> > The graphics users _want_ to use large folios.  I'm pretty sure they've
> > been tested with this.
> 
> Correct. We've done quite a bit of optimization in userspace and
> enabling in kernel to take advantage of page sizes of 2M and beyond.
> 
> However we specifically pass "huge=within_size" to vfs_kern_mount when
> creating a private mount of tmpfs for the purpose of i915 created
> allocations.
> 
> Older hardware also had some address hashing bugs where 2M aligned
> memory caused a lot of collisions in TLB so we don't enable it always.
> 
> You can see drivers/gpu/drm/i915/gem/i915_gemfs.c function
> i915_gemfs_init for details and references.
> 
> So in short, functionality wise we should be fine either default
> for using 2M pages or not. If they become the default, we'd probably
> want an option that would still be able to prevent them for performance
> regression reasons on older hardware.

To maybe write out my concern better:

Is there plan to enable huge pages by default in shmem?

If not I guess we should be pretty good with the way current code is, force
enabling them just might bring out some performance, so we might want to add
a warning for that.

If there is, then we'll probably want to in sync with those default changes
apply a similar call to block them on older HW.

Regards, Joonas

> 
> Regards, Joonas
> 
> > It's just XFS that didn't know about this
> > feature of shmem.

WARNING: multiple messages have this Message-ID (diff)
From: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
To: Christoph Hellwig <hch@lst.de>, Matthew Wilcox <willy@infradead.org>
Cc: "Darrick J . Wong" <djwong@kernel.org>,
	Dave Hansen <dave.hansen@linux.intel.com>,
	dri-devel@lists.freedesktop.org,
	David Howells <dhowells@redhat.com>,
	linux-mm@kvack.org, Huang Rui <ray.huang@amd.com>,
	David Airlie <airlied@gmail.com>,
	x86@kernel.org, Hugh Dickins <hughd@google.com>,
	Thomas Zimmermann <tzimmermann@suse.de>,
	intel-gfx@lists.freedesktop.org,
	Maxime Ripard <mripard@kernel.org>,
	Rodrigo Vivi <rodrigo.vivi@intel.com>,
	linux-sgx@vger.kernel.org, Jarkko Sakkinen <jarkko@kernel.org>,
	keyrings@vger.kernel.org, Daniel Vetter <daniel@ffwll.ch>,
	linux-fsdevel@vger.kernel.org,
	Andrew Morton <akpm@linux-foundation.org>,
	Christian Koenig <christian.koenig@amd.com>,
	Chandan Babu R <chandan.babu@oracle.com>
Subject: Re: disable large folios for shmem file used by xfs xfile
Date: Wed, 10 Jan 2024 17:28:22 +0200	[thread overview]
Message-ID: <170490050245.164862.16261803493864298341@jlahtine-mobl.ger.corp.intel.com> (raw)
In-Reply-To: <170490002493.164187.5401160425746227111@jlahtine-mobl.ger.corp.intel.com>

Quoting Joonas Lahtinen (2024-01-10 17:20:24)
> Quoting Matthew Wilcox (2024-01-10 14:37:18)
> > On Wed, Jan 10, 2024 at 10:21:07AM +0100, Christoph Hellwig wrote:
> > > Hi all,
> > > 
> > > Darrick reported that the fairly new XFS xfile code blows up when force
> > > enabling large folio for shmem.  This series fixes this quickly by disabling
> > > large folios for this particular shmem file for now until it can be fixed
> > > properly, which will be a lot more invasive.
> > > 
> > > I've added most of you to the CC list as I suspect most other users of
> > > shmem_file_setup and friends will have similar issues.
> > 
> > The graphics users _want_ to use large folios.  I'm pretty sure they've
> > been tested with this.
> 
> Correct. We've done quite a bit of optimization in userspace and
> enabling in kernel to take advantage of page sizes of 2M and beyond.
> 
> However we specifically pass "huge=within_size" to vfs_kern_mount when
> creating a private mount of tmpfs for the purpose of i915 created
> allocations.
> 
> Older hardware also had some address hashing bugs where 2M aligned
> memory caused a lot of collisions in TLB so we don't enable it always.
> 
> You can see drivers/gpu/drm/i915/gem/i915_gemfs.c function
> i915_gemfs_init for details and references.
> 
> So in short, functionality wise we should be fine either default
> for using 2M pages or not. If they become the default, we'd probably
> want an option that would still be able to prevent them for performance
> regression reasons on older hardware.

To maybe write out my concern better:

Is there plan to enable huge pages by default in shmem?

If not I guess we should be pretty good with the way current code is, force
enabling them just might bring out some performance, so we might want to add
a warning for that.

If there is, then we'll probably want to in sync with those default changes
apply a similar call to block them on older HW.

Regards, Joonas

> 
> Regards, Joonas
> 
> > It's just XFS that didn't know about this
> > feature of shmem.

  reply	other threads:[~2024-01-10 15:28 UTC|newest]

Thread overview: 48+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-01-10  9:21 disable large folios for shmem file used by xfs xfile Christoph Hellwig
2024-01-10  9:21 ` Christoph Hellwig
2024-01-10  9:21 ` [PATCH 1/2] mm: add a mapping_clear_large_folios helper Christoph Hellwig
2024-01-10  9:21   ` Christoph Hellwig
2024-01-10  9:21 ` [PATCH 2/2] xfs: disable large folio support in xfile_create Christoph Hellwig
2024-01-10  9:21   ` Christoph Hellwig
2024-01-10 17:55   ` Darrick J. Wong
2024-01-10 17:55     ` Darrick J. Wong
2024-01-10 17:55     ` Darrick J. Wong
2024-01-10 20:04     ` Darrick J. Wong
2024-01-10 20:04       ` Darrick J. Wong
2024-01-10 20:04       ` Darrick J. Wong
2024-01-11 22:00       ` Andrew Morton
2024-01-11 22:00         ` Andrew Morton
2024-01-11 22:00         ` Andrew Morton
2024-01-11 22:45         ` Matthew Wilcox
2024-01-11 22:45           ` Matthew Wilcox
2024-01-11 22:45           ` Matthew Wilcox
2024-01-12  2:22           ` Darrick J. Wong
2024-01-12  2:22             ` Darrick J. Wong
2024-01-12  2:22             ` Darrick J. Wong
2024-02-08  1:56             ` Andrew Morton
2024-02-08 16:03               ` Darrick J. Wong
2024-01-10 12:37 ` disable large folios for shmem file used by xfs xfile Matthew Wilcox
2024-01-10 12:37   ` Matthew Wilcox
2024-01-10 12:37   ` Matthew Wilcox
2024-01-10 15:20   ` Joonas Lahtinen
2024-01-10 15:20     ` Joonas Lahtinen
2024-01-10 15:20     ` Joonas Lahtinen
2024-01-10 15:28     ` Joonas Lahtinen [this message]
2024-01-10 15:28       ` Joonas Lahtinen
2024-01-10 15:28       ` Joonas Lahtinen
2024-01-10 15:34       ` Matthew Wilcox
2024-01-10 15:34         ` Matthew Wilcox
2024-01-10 15:34         ` Matthew Wilcox
2024-01-11 21:30         ` Daniel Gomez
2024-01-11 21:30           ` Daniel Gomez
2024-01-11 21:30           ` Daniel Gomez
2024-01-10 16:18   ` Christoph Hellwig
2024-01-10 16:18     ` Christoph Hellwig
2024-01-10 14:35 ` ✗ Fi.CI.CHECKPATCH: warning for series starting with [1/2] mm: add a mapping_clear_large_folios helper Patchwork
2024-01-10 14:35 ` ✗ Fi.CI.SPARSE: " Patchwork
2024-01-10 14:54 ` ✗ Fi.CI.BAT: failure " Patchwork
2024-01-10 15:38 ` disable large folios for shmem file used by xfs xfile Andrew Morton
2024-01-10 15:38   ` Andrew Morton
2024-01-10 15:38   ` Andrew Morton
2024-01-10 16:19   ` Christoph Hellwig
2024-01-10 16:19     ` Christoph Hellwig

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=170490050245.164862.16261803493864298341@jlahtine-mobl.ger.corp.intel.com \
    --to=joonas.lahtinen@linux.intel.com \
    --cc=airlied@gmail.com \
    --cc=akpm@linux-foundation.org \
    --cc=chandan.babu@oracle.com \
    --cc=christian.koenig@amd.com \
    --cc=daniel@ffwll.ch \
    --cc=dave.hansen@linux.intel.com \
    --cc=dhowells@redhat.com \
    --cc=djwong@kernel.org \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=hch@lst.de \
    --cc=hughd@google.com \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=jani.nikula@linux.intel.com \
    --cc=jarkko@kernel.org \
    --cc=keyrings@vger.kernel.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=linux-sgx@vger.kernel.org \
    --cc=maarten.lankhorst@linux.intel.com \
    --cc=mripard@kernel.org \
    --cc=ray.huang@amd.com \
    --cc=rodrigo.vivi@intel.com \
    --cc=tvrtko.ursulin@linux.intel.com \
    --cc=tzimmermann@suse.de \
    --cc=willy@infradead.org \
    --cc=x86@kernel.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.