All of lore.kernel.org
 help / color / mirror / Atom feed
From: Christoph Hellwig <hch@lst.de>
To: Carlos Maiolino <cem@kernel.org>
Cc: Christoph Hellwig <hch@lst.de>, Jan Kara <jack@suse.cz>,
	Filip Blagojevic <filip.blagojevic@wdc.com>,
	Matthew Wilcox <willy@infradead.org>,
	Damien Le Moal <dlemoal@kernel.org>,
	linux-fsdevel@vger.kernel.org, linux-xfs@vger.kernel.org
Subject: Re: [PATCH] xfs: update BDI {io,ra}_pages values based on the RT device limits
Date: Mon, 20 Jul 2026 11:11:28 +0200	[thread overview]
Message-ID: <20260720091128.GB24062@lst.de> (raw)
In-Reply-To: <al3j0GaQaeYj0Ih8@nidhogg.toxiclabs.cc>

On Mon, Jul 20, 2026 at 11:02:15AM +0200, Carlos Maiolino wrote:
> On Tue, Jun 23, 2026 at 04:21:06PM +0200, Christoph Hellwig wrote:
> > When using XFS with a main device on an SSD that stores metadata and a RT
> > device to store data on a HDD, we fail to take the I/O sizes for the RT
> > device into accounting, leading to up to 5% slower read performance when
> > using an SSD for metadata vs storing data and metadata on the HDD.
> > 
> > Fix this up by taking the RT settings into account.  Note that this
> > updates the BDI owned by the main device, and leaves those settings in
> > place even when the file system is unmounted.  This is a bit unexpected
> > but not different from manual tuning through sysfs (although that is only
> > possible for the ra_pages value).
> 
> Sorry a 'very late reply', but...
> On a second thought, wouldn't be wise to cache the original value in
> memory and restore it during unmount/filesystem shutdown?
> 
> I could send a patch to complement this one if you guys agree, otherwise
> just ignore me.

As mentioned this does seem like a valid option, there's tradeoff
both ways.  Although we'd also want a flag to avoid restoring them
if they were changed while mounted so it would get a bit more
complicated.  Happy to respin it for that if there is a general
preference.


  reply	other threads:[~2026-07-20  9:11 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-06-23 14:21 update BDI {io,ra}_pages values based on the RT device limits Christoph Hellwig
2026-06-23 14:21 ` [PATCH] xfs: " Christoph Hellwig
2026-07-02 22:25   ` Damien Le Moal
2026-07-20  9:02   ` Carlos Maiolino
2026-07-20  9:11     ` Christoph Hellwig [this message]
2026-07-20  9:38       ` Carlos Maiolino
2026-06-24 10:40 ` Carlos Maiolino
2026-06-24 15:42   ` Christoph Hellwig
2026-06-24 12:26 ` Jan Kara
2026-06-24 13:49   ` Christoph Hellwig
2026-06-25 11:12     ` Jan Kara
2026-06-25 13:09       ` Christoph Hellwig
2026-06-29 12:46 ` Christoph Hellwig
  -- strict thread matches above, loose matches on Subject: below --
2026-07-20 14:08 update BDI {io,ra}_pages values based on the RT device limits v2 Christoph Hellwig
2026-07-20 14:08 ` [PATCH] xfs: update BDI {io,ra}_pages values based on the RT device limits Christoph Hellwig
2026-07-20 23:07   ` Damien Le Moal
2026-07-21  4:30     ` Christoph Hellwig
2026-07-21  9:23       ` Carlos Maiolino
2026-07-21 15:18         ` Darrick J. Wong
2026-07-21  9:24   ` Carlos Maiolino
2026-07-21 10:44   ` Carlos Maiolino

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=20260720091128.GB24062@lst.de \
    --to=hch@lst.de \
    --cc=cem@kernel.org \
    --cc=dlemoal@kernel.org \
    --cc=filip.blagojevic@wdc.com \
    --cc=jack@suse.cz \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-xfs@vger.kernel.org \
    --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 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.