mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Christian Brauner <brauner@kernel.org>
To: Jan Kara <jack@suse.cz>
Cc: Baokun Li <libaokun1@huawei.com>,
	torvalds@linux-foundation.org,  viro@zeniv.linux.org.uk,
	willy@infradead.org, akpm@linux-foundation.org,
	 linux-kernel@vger.kernel.org, yi.zhang@huawei.com,
	yangerkun@huawei.com, yukuai3@huawei.com,
	 linux-fsdevel@vger.kernel.org
Subject: Re: [PATCH 0/2] fs: make the i_size_read/write helpers be smp_load_acquire/store_release()
Date: Wed, 24 Jan 2024 12:20:52 +0100	[thread overview]
Message-ID: <20240124-abspaltung-fernab-8f058be5e9bf@brauner> (raw)
In-Reply-To: <20240123185622.ssscyrrw5mjqjdyh@quack3>

On Tue, Jan 23, 2024 at 07:56:22PM +0100, Jan Kara wrote:
> On Mon 22-01-24 12:14:52, Christian Brauner wrote:
> > On Mon, 22 Jan 2024 17:45:34 +0800, Baokun Li wrote:
> > > This patchset follows the linus suggestion to make the i_size_read/write
> > > helpers be smp_load_acquire/store_release(), after which the extra smp_rmb
> > > in filemap_read() is no longer needed, so it is removed.
> > > 
> > > Functional tests were performed and no new problems were found.
> > > 
> > > Here are the results of unixbench tests based on 6.7.0-next-20240118 on
> > > arm64, with some degradation in single-threading and some optimization in
> > > multi-threading, but overall the impact is not significant.
> > > 
> > > [...]
> > 
> > Hm, we can certainly try but I wouldn't rule it out that someone will
> > complain aobut the "non-significant" degradation in single-threading.
> > We'll see. Let that performance bot chew on it for a bit as well.
> 
> Yeah, over 5% regression in buffered read/write cost is a bit hard to
> swallow. I somewhat wonder why this is so much - maybe people call
> i_size_read() without thinking too much and now it becomes atomic op on
> arm? Also LKP tests only on x86 (where these changes are going to be
> for noop) and I'm not sure anybody else runs performance tests on
> linux-next, even less so on ARM... So not sure anybody will complain until
> this gets into some distro (such as Android).

The LKP thing does iirc. We get reports from them quite often but there's
no way to request a test on a specific branch and get a result in some
timeframe (1 week would already be great) back. That's what I'd really like.

And similar for the build tests from the intel build bot it would be
nice if one could opt-in to get notifications that no performance
regression did indeed happen.

> 
> > But I agree that the smp_load_acquire()/smp_store_release() is clearer
> > than the open-coded smp_rmb().
> 
> Agreed, conceptually this is nice and it will also silence some KCSAN
> warnings about i_size updates vs reads.
> 
> 								Honza
> -- 
> Jan Kara <jack@suse.com>
> SUSE Labs, CR

      parent reply	other threads:[~2024-01-24 11:20 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-01-22  9:45 Baokun Li
2024-01-22  9:45 ` [PATCH 1/2] " Baokun Li
2024-01-22  9:45 ` [PATCH 2/2] Revert "mm/filemap: avoid buffered read/write race to read inconsistent data" Baokun Li
2024-01-22 11:14 ` [PATCH 0/2] fs: make the i_size_read/write helpers be smp_load_acquire/store_release() Christian Brauner
2024-01-22 12:25   ` Baokun Li
2024-01-23 18:56   ` Jan Kara
2024-01-24  8:06     ` Baokun Li
2024-01-24 11:20     ` Christian Brauner [this message]

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=20240124-abspaltung-fernab-8f058be5e9bf@brauner \
    --to=brauner@kernel.org \
    --cc=akpm@linux-foundation.org \
    --cc=jack@suse.cz \
    --cc=libaokun1@huawei.com \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=torvalds@linux-foundation.org \
    --cc=viro@zeniv.linux.org.uk \
    --cc=willy@infradead.org \
    --cc=yangerkun@huawei.com \
    --cc=yi.zhang@huawei.com \
    --cc=yukuai3@huawei.com \
    /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

all inboxes | Powered by JetHome®