From: Tom Rini <trini@konsulko.com>
To: Simon Glass <sjg@chromium.org>
Cc: Heinrich Schuchardt <xypron.glpk@gmx.de>,
Guillaume La Roque <glaroque@baylibre.com>,
Marek Vasut <marex@denx.de>,
Mattijs Korpershoek <mkorpershoek@baylibre.com>,
Sughosh Ganu <sughosh.ganu@linaro.org>,
U-Boot Mailing List <u-boot@lists.denx.de>,
Ilias Apalodimas <ilias.apalodimas@linaro.org>
Subject: Re: [PATCH 0/8] efi_loader: Complete the bootflow_efi() test
Date: Sat, 18 Jan 2025 11:15:21 -0600 [thread overview]
Message-ID: <20250118171521.GA3476@bill-the-cat> (raw)
In-Reply-To: <CAFLszThscvJzBrnSovQsrMr5ie75NVc1yUss0-c_WZLksC7Rcg@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2110 bytes --]
On Fri, Jan 17, 2025 at 08:35:42PM -0800, Simon Glass wrote:
[snip]
> > > At present 'ut all' fails so I am going to take a look at that. Quite
> > > a bit of clean-up needed in test system, though. Ideally we could run
> > > the tests in random order so we can find and fix the dependencies. For
> > > driver model we reinit as needed, but that's not the case for EFI, for
> > > example.
> >
> > Personally, for making pytest faster I'd look at the general
> > recommendations various blog posts about "make your pytest run faster"
> > and then go from there.
>
> I think the problem is that you are looking at the C tests through a Python
> lens, so everything seems a bit slow.
>
> 'ut all' takes about 18 seconds for me.
Yes, and the "ut" tests just via pytest do take longer. And it would be
good to have more testing in CI, and for tests to be as fast as
possible.
Looking at the run I just did on HW:
====================== 202 passed, 426 skipped in 48.76s =======================
================= 202 passed, 426 skipped in 80.04s (0:01:20) ==================
================= 206 passed, 422 skipped in 128.74s (0:02:08) =================
================= 206 passed, 422 skipped in 118.15s (0:01:58) =================
================= 206 passed, 422 skipped in 128.65s (0:02:08) =================
================= 206 passed, 422 skipped in 123.76s (0:02:03) =================
================= 205 passed, 423 skipped in 128.22s (0:02:08) =================
================= 198 passed, 429 skipped in 106.92s (0:01:46) =================
================= 192 passed, 431 skipped in 87.95s (0:01:27) ==================
That could be better, but it's not unreasonable and part of that is
tftp'ing an 83MB kernel image.
I think if I had a point around here before, it was this. C is a
terrible language for processing strings. Python is a reasonable
language for processing strings. Neither of these statements should be
controversial. The controversy is that I'm saying tests that parse
output for results shouldn't be written in C.
--
Tom
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]
next prev parent reply other threads:[~2025-01-18 17:15 UTC|newest]
Thread overview: 35+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-01-06 14:47 [PATCH 0/8] efi_loader: Complete the bootflow_efi() test Simon Glass
2025-01-06 14:47 ` [PATCH 1/8] sandbox: Make USB controller as having active DMA Simon Glass
2025-01-06 14:47 ` [PATCH 2/8] efi_loader: Fix display of addresses in log Simon Glass
2025-01-07 13:37 ` Ilias Apalodimas
2025-01-07 13:57 ` Simon Glass
2025-01-08 7:12 ` Ilias Apalodimas
2025-01-08 17:03 ` Simon Glass
2025-01-06 14:47 ` [PATCH 3/8] efi_loader: Return the memory map in pointer format Simon Glass
2025-01-06 14:47 ` [PATCH 4/8] efi_loader: Correct bounce-buffer setup Simon Glass
2025-01-17 10:33 ` Ilias Apalodimas
2025-01-18 4:35 ` Simon Glass
2025-01-06 14:47 ` [PATCH 5/8] efi_loader: Check memory allocations in bootflow_efi test() Simon Glass
2025-01-06 14:47 ` [PATCH 6/8] efi_loader: Update testapp to get memory map correctly Simon Glass
2025-01-06 14:47 ` [PATCH 7/8] efi_loader: Check that the bootflow is not removed by app Simon Glass
2025-01-06 14:47 ` [PATCH 8/8] efi_loader: Test that active-DMA devices are removed Simon Glass
2025-01-06 17:00 ` [PATCH 0/8] efi_loader: Complete the bootflow_efi() test Heinrich Schuchardt
2025-01-07 12:15 ` Simon Glass
2025-01-07 13:11 ` Heinrich Schuchardt
2025-01-07 13:57 ` Simon Glass
2025-01-07 15:11 ` Tom Rini
2025-01-07 15:47 ` Heinrich Schuchardt
2025-01-08 13:39 ` Caleb Connolly
2025-01-08 17:02 ` Simon Glass
2025-01-08 17:02 ` Simon Glass
2025-01-08 19:14 ` Tom Rini
2025-01-09 15:02 ` Simon Glass
2025-01-09 16:51 ` Tom Rini
2025-01-10 13:40 ` Simon Glass
2025-01-10 16:48 ` Tom Rini
2025-01-13 19:01 ` Simon Glass
2025-01-13 20:20 ` Tom Rini
2025-01-18 4:35 ` Simon Glass
2025-01-18 17:03 ` Tom Rini
2025-01-18 17:15 ` Tom Rini [this message]
2025-01-31 0:10 ` Simon Glass
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=20250118171521.GA3476@bill-the-cat \
--to=trini@konsulko.com \
--cc=glaroque@baylibre.com \
--cc=ilias.apalodimas@linaro.org \
--cc=marex@denx.de \
--cc=mkorpershoek@baylibre.com \
--cc=sjg@chromium.org \
--cc=sughosh.ganu@linaro.org \
--cc=u-boot@lists.denx.de \
--cc=xypron.glpk@gmx.de \
/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