From: Dave Chinner <david@fromorbit.com>
To: fstests@vger.kernel.org
Subject: Re: [PATCH v2] fstests: faster group file creation
Date: Fri, 6 May 2022 17:44:24 +1000 [thread overview]
Message-ID: <20220506074424.GG1949718@dread.disaster.area> (raw)
In-Reply-To: <20220506071311.uhdgdzl26zajdclm@zlang-mailbox>
On Fri, May 06, 2022 at 03:13:11PM +0800, Zorro Lang wrote:
> On Fri, May 06, 2022 at 03:10:17PM +1000, Dave Chinner wrote:
> > From: Dave Chinner <dchinner@redhat.com>
> >
> > We don't need to execute every test just to check it's groups are
> > valid. Just grab all the groups with grep, pull out the unique ones,
> > then check them.
> >
> > This also avoids the problem of editor swap files being present in
> > the test directory and breaking the build because they are not
> > executable.
> >
> > Building on a clean, already built tree so it only builds the
> > group lists:
> >
> > $ time make
> > ....
> > Building udf
> > [GROUP] /home/dave/src/xfstests-dev/tests/udf/group.list
> > Building xfs
> > [GROUP] /home/dave/src/xfstests-dev/tests/xfs/group.list
> >
> > real 0m36.917s
> > user 0m15.032s
> > sys 0m26.219s
> > $
> >
> > Patched:
> >
> > $ time make
> > ....
> > Building udf
> > [GROUP] /home/dave/src/xfstests-dev/tests/udf/group.list
> > Building xfs
> > [GROUP] /home/dave/src/xfstests-dev/tests/xfs/group.list
> > groups "frobnozzle" not mentioned in documentation.
> > gmake[3]: *** [../../include/buildgrouplist:8: group.list] Error 1
> > gmake[2]: *** [../include/buildrules:31: xfs] Error 2
> > gmake[1]: *** [include/buildrules:31: tests] Error 2
> > make: *** [Makefile:51: default] Error 2
> >
> > real 0m1.751s
> > user 0m0.863s
> > sys 0m1.067s
> >
> > $
> >
> > Just a little bit faster, and as you can see that it still detects
> > groups that are not documented. There was also an open .001.swp file
> > in the XFS directory and that doesn't throw a failure anymore,
> > either.
> >
> > Signed-off-by: Dave Chinner <dchinner@redhat.com>
> > ---
>
> Looks good to me. It's much faster than before, especially when rebuild for
> small changes.
Yup, my run scripts always run make before starting a run, so when
I'm iterating single tests for failure analysis, this knocks 20-30s
out of the cycle time. check starting up is now the thing that is
really slow - it's still taking around 10s to get to the first
test these days....
> Reviewed-by: Zorro Lang <zlang@kernel.org>
Thanks!
-Dave.
--
Dave Chinner
david@fromorbit.com
prev parent reply other threads:[~2022-05-06 7:44 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-05-06 3:12 [PATCH] fstests: faster group file creation Dave Chinner
2022-05-06 4:42 ` Dave Chinner
2022-05-06 5:10 ` [PATCH v2] " Dave Chinner
2022-05-06 7:13 ` Zorro Lang
2022-05-06 7:44 ` Dave Chinner [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=20220506074424.GG1949718@dread.disaster.area \
--to=david@fromorbit.com \
--cc=fstests@vger.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.