From: Mark Brown <broonie@kernel.org>
To: Ryan Roberts <ryan.roberts@arm.com>
Cc: "Andrew Morton" <akpm@linux-foundation.org>,
"Shuah Khan" <shuah@kernel.org>,
"Jérôme Glisse" <jglisse@redhat.com>,
"David Hildenbrand" <david@redhat.com>,
"John Hubbard" <jhubbard@nvidia.com>,
"Florent Revest" <revest@chromium.org>,
"Liam R. Howlett" <Liam.Howlett@oracle.com>,
linux-kernel@vger.kernel.org, linux-mm@kvack.org,
linux-kselftest@vger.kernel.org
Subject: Re: [PATCH v1 1/9] selftests: Line buffer test program's stdout
Date: Thu, 13 Jul 2023 15:16:24 +0100 [thread overview]
Message-ID: <8a8d077c-55bd-4710-9dfd-1cbb1a9170a8@sirena.org.uk> (raw)
In-Reply-To: <20230713135440.3651409-2-ryan.roberts@arm.com>
[-- Attachment #1: Type: text/plain, Size: 1357 bytes --]
On Thu, Jul 13, 2023 at 02:54:32PM +0100, Ryan Roberts wrote:
> The selftests runner pipes the test program's stdout to tap_prefix. The
> presence of the pipe means that the test program sets its stdout to be
> fully buffered (as aposed to line buffered when directly connected to
> the terminal). The block buffering means that there is often content in
> the buffer at fork() time, which causes the output to end up duplicated.
> This was causing problems for mm:cow where test results were duplicated
> 20-30x.
>
> Solve this by using `stdbuf`, when available to force the test program
> to use line buffered mode. This means previously printf'ed results are
> flushed out of the program before any fork().
This is going to be useful in general since not all selftests use the
kselftest helpers but it'd probably also be good to make
ksft_print_header() also make the output unbuffered so that if setbuf
isn't installed on the target system or the tests are run standalone we
don't run into issues there. Even if the test isn't corrupting data
having things unbuffered is going to be good for making sure we don't
drop any output if the test dies.
> + if [ -x /usr/bin/stdbuf ]; then
> + stdbuf="/usr/bin/stdbuf --output=L "
> + fi
Might be more robust to use type -p to find stdbuf in case it's in /bin
or something?
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
next prev parent reply other threads:[~2023-07-13 14:16 UTC|newest]
Thread overview: 40+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-07-13 13:54 [PATCH v1 0/9] selftests/mm fixes for arm64 Ryan Roberts
2023-07-13 13:54 ` [PATCH v1 1/9] selftests: Line buffer test program's stdout Ryan Roberts
2023-07-13 14:16 ` Mark Brown [this message]
2023-07-13 14:32 ` Ryan Roberts
2023-07-13 14:45 ` Mark Brown
2023-07-17 8:36 ` Ryan Roberts
2023-07-13 13:54 ` [PATCH v1 2/9] selftests/mm: Give scripts execute permission Ryan Roberts
2023-07-13 14:39 ` David Hildenbrand
2023-07-13 17:32 ` SeongJae Park
2023-07-14 9:44 ` Ryan Roberts
2023-07-14 16:00 ` SeongJae Park
2023-07-14 16:11 ` Mark Brown
2023-07-14 16:26 ` Andrew Morton
2023-07-14 16:28 ` Ryan Roberts
2023-07-13 13:54 ` [PATCH v1 3/9] selftests/mm: Skip soft-dirty tests on arm64 Ryan Roberts
2023-07-13 13:56 ` David Hildenbrand
2023-07-13 14:03 ` Ryan Roberts
2023-07-13 14:09 ` David Hildenbrand
2023-07-13 14:12 ` David Hildenbrand
2023-07-13 14:16 ` Ryan Roberts
2023-07-13 14:14 ` Ryan Roberts
2023-07-13 14:29 ` David Hildenbrand
2023-07-15 0:04 ` John Hubbard
2023-07-17 8:23 ` Ryan Roberts
2023-07-13 13:54 ` [PATCH v1 4/9] selftests/mm: Enable mrelease_test for arm64 Ryan Roberts
2023-07-13 14:32 ` David Hildenbrand
2023-07-13 13:54 ` [PATCH v1 5/9] selftests/mm: Fix thuge-gen test bugs Ryan Roberts
2023-07-13 13:54 ` [PATCH v1 6/9] selftests/mm: va_high_addr_switch should skip unsupported arm64 configs Ryan Roberts
2023-07-13 14:41 ` David Hildenbrand
2023-07-13 13:54 ` [PATCH v1 7/9] selftests/mm: Make migration test robust to failure Ryan Roberts
2023-07-13 13:54 ` [PATCH v1 8/9] selftests/mm: Optionally pass duration to transhuge-stress Ryan Roberts
2023-07-13 13:54 ` [PATCH v1 9/9] selftests/mm: Run all tests from run_vmtests.sh Ryan Roberts
2023-07-13 14:50 ` David Hildenbrand
2023-07-13 15:04 ` Ryan Roberts
2023-07-13 15:25 ` David Hildenbrand
2023-07-13 15:30 ` Ryan Roberts
2023-07-13 15:30 ` Mark Brown
2023-07-13 15:36 ` Ryan Roberts
2023-07-13 15:43 ` Mark Brown
2023-07-13 15:46 ` Ryan Roberts
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=8a8d077c-55bd-4710-9dfd-1cbb1a9170a8@sirena.org.uk \
--to=broonie@kernel.org \
--cc=Liam.Howlett@oracle.com \
--cc=akpm@linux-foundation.org \
--cc=david@redhat.com \
--cc=jglisse@redhat.com \
--cc=jhubbard@nvidia.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-kselftest@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=revest@chromium.org \
--cc=ryan.roberts@arm.com \
--cc=shuah@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox