From: Chuck Lever III <chuck.lever@oracle.com>
To: Steve French <smfrench@gmail.com>
Cc: Amir Goldstein <amir73il@gmail.com>,
Luis Chamberlain <mcgrof@kernel.org>,
"lsf-pc@lists.linux-foundation.org"
<lsf-pc@lists.linux-foundation.org>,
"kdevops@lists.linux.dev" <kdevops@lists.linux.dev>,
Linux FS Devel <linux-fsdevel@vger.kernel.org>,
linux-mm <linux-mm@kvack.org>,
"linux-cxl@vger.kernel.org" <linux-cxl@vger.kernel.org>,
Jan Kara <jack@suse.cz>
Subject: Re: kdevops BoF at LSFMM
Date: Wed, 8 May 2024 17:54:50 +0000 [thread overview]
Message-ID: <E2589F86-7582-488C-9DBB-8022D481AFB3@oracle.com> (raw)
In-Reply-To: <CAH2r5mt=CRQXdVHiXMCEwtyEXt-r-oENdESwF5k+vEww-JkWCg@mail.gmail.com>
> On May 8, 2024, at 1:45 PM, Steve French <smfrench@gmail.com> wrote:
>
> I would be very happy if there were an easy way to do three things
> faster/easier:
> 1) make it easier to run a reasonably large set of fs tests automatically
> on checkin of a commit or set of commits (e.g. to an externally visible
> github branch) before it goes in linux-next, and a larger set
> of test automation that is automatically run on P/Rs (I kick these tests
> off semi-manually for cifs.ko and ksmbd.ko today)
> 2) make it easier as a maintainer to get reports of automated testing of
> stable-rc (or automate running of tests against stable-rc by filesystem type
> and send failures to the specific fs's mailing list). Make the tests run
> for a particular fs more visible, so maintainers/contributors can note
> where important tests are left out against a particular fs
In my experience, these require the addition of a CI
apparatus like BuildBot or Jenkins -- they are not
directly part of kdevops' mission. Scott Mayhew and
I have been playing with BuildBot, and there are some
areas where integration between kdevops and BuildBot
could be improved (and could be discussed next week).
> 3) make it easier to auto-bisect what commit regressed when a failing test
> is spotted
Jeff Layton has mentioned this as well. I don't think
it would be impossible to get kdevops to orchestrate
a bisect, as long as it has an automatic way to decide
when to use "git bisect {good|bad}"
> 6) an easy way to tell if a kdevops run is "suspiciously slow" (ie if a test
> or set of tests is more than 20% slower than the baseline test run, it
> could indicate a performance regression that needs to be bisected
> and identified)
Well sometimes things are just slow because you've built
a test kernel with KASAN and lockdep, or because there are
other jobs running on your test system. Also, due to all
the virtualization involved, it might be difficult to get
consistent performance measurements.
This one seems like it would be hard to engineer, but maybe
there's something that could be done?
--
Chuck Lever
next prev parent reply other threads:[~2024-05-08 17:55 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-05-07 18:44 kdevops BoF at LSFMM Luis Chamberlain
2024-05-07 18:56 ` Chuck Lever III
2024-05-08 7:45 ` Amir Goldstein
2024-05-08 15:57 ` Luis Chamberlain
2024-05-13 1:58 ` Matthew Wilcox
2024-05-08 17:45 ` Steve French
2024-05-08 17:54 ` Chuck Lever III [this message]
2024-05-12 20:20 ` Luis Chamberlain
2024-05-13 13:17 ` Theodore Ts'o
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=E2589F86-7582-488C-9DBB-8022D481AFB3@oracle.com \
--to=chuck.lever@oracle.com \
--cc=amir73il@gmail.com \
--cc=jack@suse.cz \
--cc=kdevops@lists.linux.dev \
--cc=linux-cxl@vger.kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=lsf-pc@lists.linux-foundation.org \
--cc=mcgrof@kernel.org \
--cc=smfrench@gmail.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;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).