From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id DE4A6C4321E for ; Tue, 29 Nov 2022 00:05:39 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:MIME-Version:References:In-Reply-To: Message-Id:Date:Subject:Cc:To:From:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=Ea/MAGgVVQe7Alnfm8JRxQC7afi3l8V+ah6wjWjMauY=; b=1Kqp3c1C2lfgwh MBUQwarpXyLmjGHpIu8OW2gKx3SWdVMh2NOSxqlw/DXAmqqs5WsXgigREny2iS+0leY8yP3PIP2kp I21tTe1rToEho2J+CEjm9bxXkSxGB0xmmxCo7lH+PyVOChmb+Sy3tJMy57uQbgAcsqv6din2b0i0t yz1ld373s2ApNjgxbWu0mQgN/FcpoaflDpSMkBO4aWDMUfoCLdlgLWmB/AqI6JPk4tdDChSxF4U72 bf15t8lpnCo08Uus6Hnjej0ThhnAfcWLsekFMlkwIEZB7dPoZCS6ZX3IC0cMnsIomHPRTPLWKcwO7 /Nk9eGug1XaRsZUO8Sdg==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1ozo79-004qdx-IN; Tue, 29 Nov 2022 00:04:43 +0000 Received: from ams.source.kernel.org ([145.40.68.75]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1ozo6r-004qYH-7d for linux-arm-kernel@lists.infradead.org; Tue, 29 Nov 2022 00:04:27 +0000 Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ams.source.kernel.org (Postfix) with ESMTPS id C927AB8102B; Tue, 29 Nov 2022 00:04:22 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 26D4DC4347C; Tue, 29 Nov 2022 00:04:19 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1669680261; bh=NDM4IpK1Mj0AGBGcu4ocxuGv8IyHd9RxuVw91kBfjLo=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=R02H6km0mIoxwI3OT9rRXqBt7YZygebWS1uPDvA/Vl4sZ469lqyNpPWBzQ4IVdwr6 uup7bY4f8q/AYVGlFWd0e3AqzN0D95wCdW4mlbXVWhI79bDgmk9PHQNWs+sZQmrX9B Y/2PFGskzzWo1cb2ZxHLeSh4r4WAUKdfd6wGP1XPfRshq9FZMtRHq95NOJR2x+9bWH 3opLYBZkBL1XKceV8I9EefYD0ENW82LPPVevCjmTYEIcXoOlNO3NkRhbhvoVsbkToU c4Afhx7cobUf2lyjOLVGGecAC8l3kq0aT6yTmMsO/m1WBMLh3BPBQUBl+KF6GWPANe VYop4bY57tu/Q== From: Mark Brown To: Catalin Marinas , Will Deacon , Shuah Khan Cc: linux-arm-kernel@lists.infradead.org, linux-kselftest@vger.kernel.org, Mark Brown Subject: [PATCH v1 1/3] kselftest/arm64: Hold fp-stress children until they're all spawned Date: Tue, 29 Nov 2022 00:03:53 +0000 Message-Id: <20221129000355.812425-2-broonie@kernel.org> X-Mailer: git-send-email 2.30.2 In-Reply-To: <20221129000355.812425-1-broonie@kernel.org> References: <20221129000355.812425-1-broonie@kernel.org> MIME-Version: 1.0 X-Developer-Signature: v=1; a=openpgp-sha256; l=3511; i=broonie@kernel.org; h=from:subject; bh=NDM4IpK1Mj0AGBGcu4ocxuGv8IyHd9RxuVw91kBfjLo=; b=owEBbQGS/pANAwAKASTWi3JdVIfQAcsmYgBjhUxoJLgwylCPMbz6VfJBPb5ktw1QGE8a0BHY8MTS duAFTMqJATMEAAEKAB0WIQSt5miqZ1cYtZ/in+ok1otyXVSH0AUCY4VMaAAKCRAk1otyXVSH0Ie6B/ 90SBqTu2fvepPiFTNRyZ8WWrDfM+sKbHwoKfxCPK0/YklTnACBRzPY5aUoHrPfLKqiPLBShlL1wlyN D/hr32ZBjIPocjNKUVJLm+kqUn0YHp3hxANSJDadS8EVnjqehWnnmq7gvzeVVlsKwmFnwGs50SsBfr 62q2T3FiwfKiQhktVuVpwym5cb8WwmLJiC8ya6+Z8ID1rVZGJPZKQ0HXZ98NKhv/fTYXz0k5UEA8w7 HENfjH1jp2k0rlJxpkd/PSZYg+N6A7rkNDT2WPd8d/cM7MmLYP7nBHxa35NaIp/Mhdocd1s9oWQljN bpLu3qDxHQoFD4GNXEtWup5rt8Groi X-Developer-Key: i=broonie@kernel.org; a=openpgp; fpr=3F2568AAC26998F9E813A1C5C3F436CA30F5D8EB X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20221128_160425_681851_0A0E0542 X-CRM114-Status: GOOD ( 20.44 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org At present fp-stress has a bit of a thundering herd problem since the children it spawns start running immediately, meaning that they can start starving the parent process of CPU before it has even started all the children. This is much more severe on virtual platforms since they tend to support far more SVE and SME vector lengths, be slower in general and for some have issues with performance when simulating multiple CPUs. We can mitigate this problem by having all the child processes block before starting the test program, meaning that we at least have all the child processes started before we start heavily using CPU. We still have the same load issues while waiting for the actual stress test programs to start up and produce output but they're at least all ready to go before that kicks in, resulting in substantial reductions in overall runtime on some of the severely affected systems. One test was showing about 20% improvement. Signed-off-by: Mark Brown --- tools/testing/selftests/arm64/fp/fp-stress.c | 41 +++++++++++++++++++- 1 file changed, 40 insertions(+), 1 deletion(-) diff --git a/tools/testing/selftests/arm64/fp/fp-stress.c b/tools/testing/selftests/arm64/fp/fp-stress.c index 4e62a9199f97..9a3a621cc958 100644 --- a/tools/testing/selftests/arm64/fp/fp-stress.c +++ b/tools/testing/selftests/arm64/fp/fp-stress.c @@ -44,6 +44,8 @@ static bool terminate; static void drain_output(bool flush); +static int startup_pipe[2]; + static int num_processors(void) { long nproc = sysconf(_SC_NPROCESSORS_CONF); @@ -81,13 +83,37 @@ static void child_start(struct child_data *child, const char *program) exit(EXIT_FAILURE); } + /* + * Duplicate the read side of the startup pipe to + * FD 3 so we can close everything else. + */ + ret = dup2(startup_pipe[0], 3); + if (ret == -1) { + fprintf(stderr, "dup2() %d\n", errno); + exit(EXIT_FAILURE); + } + /* * Very dumb mechanism to clean open FDs other than * stdio. We don't want O_CLOEXEC for the pipes... */ - for (i = 3; i < 8192; i++) + for (i = 4; i < 8192; i++) close(i); + /* + * Read from the startup pipe, there should be no data + * and we should block until it is closed. We just + * carry on on error since this isn't super critical. + */ + ret = read(3, &i, sizeof(i)); + if (ret < 0) + fprintf(stderr, "read(startp pipe) failed: %s (%d)\n", + strerror(errno), errno); + if (ret > 0) + fprintf(stderr, "%d bytes of data on startup pipe\n", + ret); + close(3); + ret = execl(program, program, NULL); fprintf(stderr, "execl(%s) failed: %d (%s)\n", program, errno, strerror(errno)); @@ -465,6 +491,12 @@ int main(int argc, char **argv) strerror(errno), ret); epoll_fd = ret; + /* Create a pipe which children will block on before execing */ + ret = pipe(startup_pipe); + if (ret != 0) + ksft_exit_fail_msg("Failed to create startup pipe: %s (%d)\n", + strerror(errno), errno); + /* Get signal handers ready before we start any children */ memset(&sa, 0, sizeof(sa)); sa.sa_sigaction = handle_exit_signal; @@ -497,6 +529,13 @@ int main(int argc, char **argv) } } + /* + * All children started, close the startup pipe and let them + * run. + */ + close(startup_pipe[0]); + close(startup_pipe[1]); + for (;;) { /* Did we get a signal asking us to exit? */ if (terminate) -- 2.30.2 _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel