All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Paul E. McKenney" <paulmck@kernel.org>
To: Willy Tarreau <w@1wt.eu>
Cc: Rasmus Villemoes <linux@rasmusvillemoes.dk>,
	linux-kselftest@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] selftests/nolibc: add 7 tests for memcmp()
Date: Wed, 26 Oct 2022 06:57:33 -0700	[thread overview]
Message-ID: <20221026135733.GK5600@paulmck-ThinkPad-P17-Gen-1> (raw)
In-Reply-To: <20221026053922.GA19206@1wt.eu>

On Wed, Oct 26, 2022 at 07:39:22AM +0200, Willy Tarreau wrote:
> Hi Paul,
> 
> On Mon, Oct 24, 2022 at 08:53:57AM -0700, Paul E. McKenney wrote:
> > > Will keep thinking about it and hopefully propose a patch to make the
> > > tests easier to use before we're too far in the 6.1 release.
> > 
> > Another possibility is to have a separate developers' and maintainers'
> > option.  Linus and I do "make whatever" for some value of "whatever"
> > that builds from scratch, doing whatever cleaning that might be required.
> > Developers use targets that are faster but have the possibility of false
> > positives and false negatives.
> > 
> > But maybe you have something better in mind.
> > 
> > > Thanks for keeping the conversation flowing, that helps me!
> > 
> > Looking forward to seeing what you come up with!
> 
> I could finally figure what was taking time in the installation process.
> Interestingly, it's "make headers", which is not redone without a "make
> clean" at the kernel level. The "make headers_install" only takes a few
> hundred milliseconds, so issuing a systematic "make clean" in the nolibc
> test dir only takes ~800ms here to perform a full rebuild, which is totally
> acceptable to me.
> 
> Thus what I've done is to mark the sysroot target as .phony and start it
> with a removal of the current include dir so that we systematically rebuild
> it. Now there's no such risk of running a test against an earlier version
> anymore, and there are no "make clean" to worry about anymore either.
> That looks much better to me!
> 
> And I could confirm that just issuing:
> 
>   $ time make -j8 -C tools/testing/selftests/nolibc run
> 
> after reverting Rasmus' fix led me to this pretty quickly:
> 
>   ...
>   Kernel: arch/x86/boot/bzImage is ready  (#3)
>   make[1]: Leaving directory '/k'
>   15 memcmp_20_e0 = 64                    [FAIL]
>   16 memcmp_e0_20 = -64                   [FAIL]
>   See all results in /k/tools/testing/selftests/nolibc/run.out
>   make: Leaving directory '/k/tools/testing/selftests/nolibc'
> 
>   real    0m14.538s
>   user    0m27.828s
>   sys     0m4.576s
> 
> No more false positives nor false negatives anymore. I'm sending you
> the patch separately.
> 
> Thanks for the discussion, the solution is way better now!

Nice, looking forward to the patch!

							Thanx, Paul

  parent reply	other threads:[~2022-10-26 13:58 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-10-21  6:03 [PATCH] selftests/nolibc: add 7 tests for memcmp() Willy Tarreau
2022-10-21 15:56 ` Paul E. McKenney
2022-10-21 17:01   ` Willy Tarreau
2022-10-21 17:07     ` Paul E. McKenney
2022-10-21 17:20       ` Willy Tarreau
2022-10-21 18:00         ` Paul E. McKenney
2022-10-22 11:22           ` Willy Tarreau
2022-10-24 15:53             ` Paul E. McKenney
2022-10-26  5:39               ` Willy Tarreau
2022-10-26  9:08                 ` Rasmus Villemoes
2022-10-26 19:52                   ` Willy Tarreau
2022-10-27  9:09                     ` Rasmus Villemoes
2022-10-27 17:20                       ` Willy Tarreau
2022-10-26 13:57                 ` Paul E. McKenney [this message]
2022-10-26 14:17                   ` Willy Tarreau

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=20221026135733.GK5600@paulmck-ThinkPad-P17-Gen-1 \
    --to=paulmck@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-kselftest@vger.kernel.org \
    --cc=linux@rasmusvillemoes.dk \
    --cc=w@1wt.eu \
    /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.