From: Gao Xiang <xiang@kernel.org>
To: Dave Chinner <david@fromorbit.com>
Cc: Gao Xiang <hsiangkao@linux.alibaba.com>,
linux-xfs <linux-xfs@vger.kernel.org>,
Zorro Lang <zlang@redhat.com>
Subject: Re: [report] Unixbench shell1 performance regression
Date: Tue, 18 Mar 2025 10:03:10 +0800 [thread overview]
Message-ID: <Z9jUXkfmDYc0Vlni@debian> (raw)
In-Reply-To: <Z9jFTdELyfwsfeKz@dread.disaster.area>
On Tue, Mar 18, 2025 at 11:58:53AM +1100, Dave Chinner wrote:
> On Tue, Mar 18, 2025 at 08:29:46AM +0800, Gao Xiang wrote:
> > On 2025/3/18 04:43, Dave Chinner wrote:
> > > On Mon, Mar 17, 2025 at 08:25:16AM +0800, Gao Xiang wrote:
> > > > If they think the results are not good, they might ask us to move away
> > > > of XFS filesystem. It's not what I could do anything, you know.
> > >
> > > If they think there is a filesystem better suited to their
> > > requirements than XFS, then they are free to make that decision
> > > themselves. We can point out that their selection metrics are
> > > irrelevant to their actual workload, but in my experience this just
> > > makes the people running the selection trial more convinced they are
> > > right and they still make a poor decision....
> >
> > The problem is not simple like this, what we'd like is to provide
> > a unique cloud image for users to use. It's impossible for us to
> > provide two images for two filesystems. But Unixbench is still
> > important for many users, so either we still to XFS or switch back
> > to EXT4.
>
> Well, that means your company has the motivation to try to improve
> the XFS code, doesn't it? If they won't put up the resources to
> address issues that affect their customers, then why should anyone
> else do that work for them for free?
Disclose: I don't speak for my company. So the following is just
my own thoughts.
It may be true in 2023, however, the only resource now is me (I
suspect there will be more resource), but I still have other work
to do on my hand which impacts my own performance review more.
For this issue, I spent much time (up to the mid-night) last week
to find out, which greatly impact my own physical health. Yes,
I will speed more on this, but:
There is no clear evidence that a cloud image could directly benefit
to our AI infra. So from POV of a company, the worst case is that
they may revisit the overall benefits among all possible choices and
find out the best one.
Anyway, I've got the community view of Unixbench. I will arrange my
own TODO list.
Thanks,
Gao Xiang
>
> -Dave.
> --
> Dave Chinner
> david@fromorbit.com
next prev parent reply other threads:[~2025-03-18 2:03 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-03-14 17:19 [report] Unixbench shell1 performance regression Gao Xiang
2025-03-16 21:25 ` Dave Chinner
2025-03-17 0:25 ` Gao Xiang
2025-03-17 20:43 ` Dave Chinner
2025-03-18 0:29 ` Gao Xiang
2025-03-18 0:58 ` Dave Chinner
2025-03-18 2:03 ` Gao Xiang [this message]
2025-03-18 8:10 ` Christoph Hellwig
2025-03-18 9:27 ` Gao Xiang
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=Z9jUXkfmDYc0Vlni@debian \
--to=xiang@kernel.org \
--cc=david@fromorbit.com \
--cc=hsiangkao@linux.alibaba.com \
--cc=linux-xfs@vger.kernel.org \
--cc=zlang@redhat.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 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.