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 alsa0.perex.cz (alsa0.perex.cz [77.48.224.243]) (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 ABB77C61DA4 for ; Sat, 4 Feb 2023 08:38:18 +0000 (UTC) Received: from alsa1.perex.cz (alsa1.perex.cz [207.180.221.201]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by alsa0.perex.cz (Postfix) with ESMTPS id 39C61F7; Sat, 4 Feb 2023 09:37:26 +0100 (CET) DKIM-Filter: OpenDKIM Filter v2.11.0 alsa0.perex.cz 39C61F7 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=alsa-project.org; s=default; t=1675499896; bh=+nI47mWoagSGGdL78gK5LOsPimhiwpMUiIAGFf7yIsE=; h=Date:From:To:Subject:In-Reply-To:References:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: Cc:From; b=dQSixdMdODxVH0dcKX1iVQiZpjGseBMPqCuuihNfMy/QYoVZ0DMwFGc5XdJC8Z04T jFTt3TLga7wwxXPJp1bW/o3ciCANI+SM1hPHteQTtaDt1FfO/TM5+2Ygul7pit3ovK y6g7gQ0L3eMteyChqh+rHsJeTMQfdfN1ZnXPGeIc= Received: from alsa1.perex.cz (localhost.localdomain [127.0.0.1]) by alsa1.perex.cz (Postfix) with ESMTP id BB576F80271; Sat, 4 Feb 2023 09:37:25 +0100 (CET) Received: by alsa1.perex.cz (Postfix, from userid 50401) id 86BBDF804C2; Sat, 4 Feb 2023 09:37:24 +0100 (CET) Received: from smtp-out1.suse.de (smtp-out1.suse.de [IPv6:2001:67c:2178:6::1c]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by alsa1.perex.cz (Postfix) with ESMTPS id BB92CF8001D for ; Sat, 4 Feb 2023 09:37:17 +0100 (CET) DKIM-Filter: OpenDKIM Filter v2.11.0 alsa1.perex.cz BB92CF8001D Authentication-Results: alsa1.perex.cz; dkim=pass (1024-bit key, unprotected) header.d=suse.de header.i=@suse.de header.a=rsa-sha256 header.s=susede2_rsa header.b=OlK2dRKW; dkim=pass header.d=suse.de header.i=@suse.de header.a=ed25519-sha256 header.s=susede2_ed25519 header.b=IN+7TwKw Received: from imap2.suse-dmz.suse.de (imap2.suse-dmz.suse.de [192.168.254.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-521) server-digest SHA512) (No client certificate requested) by smtp-out1.suse.de (Postfix) with ESMTPS id 87BD438269; Sat, 4 Feb 2023 08:37:17 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_rsa; t=1675499837; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=RcLMsHWahnKCSaF9S8/IpKCRhGBLv3jN3QszBd2oUrE=; b=OlK2dRKWt+azF90YkaeXIbGPBgQpN9AoCAuHLHSqchVc40cDyU4PaK/vO45OXl1ZPEWrAH eYGihhb8BCiKcPL5Zga796MKkBsRilYWlvXhPBd14exdJDYO9Vzflu0oLanOwSXM3sO++n Kaslvjsiq/Wz8P0HR/o9rSvjx1B5258= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_ed25519; t=1675499837; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=RcLMsHWahnKCSaF9S8/IpKCRhGBLv3jN3QszBd2oUrE=; b=IN+7TwKwomq87Iez9hcudSyREJdmtMuUtMwSgGaEddwOYtSrNqJ19Xav1pmhzadjCM2v/2 oVqarOK0C5CuNNDQ== Received: from imap2.suse-dmz.suse.de (imap2.suse-dmz.suse.de [192.168.254.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-521) server-digest SHA512) (No client certificate requested) by imap2.suse-dmz.suse.de (Postfix) with ESMTPS id 59334133F5; Sat, 4 Feb 2023 08:37:17 +0000 (UTC) Received: from dovecot-director2.suse.de ([192.168.254.65]) by imap2.suse-dmz.suse.de with ESMTPSA id XU+4FD0Z3mNqKwAAMHmgww (envelope-from ); Sat, 04 Feb 2023 08:37:17 +0000 Date: Sat, 04 Feb 2023 09:37:16 +0100 Message-ID: <877cwxn7wj.wl-tiwai@suse.de> From: Takashi Iwai To: Mark Brown Subject: Re: [PATCH] kselftest/alsa: Run PCM tests for multiple cards in parallel In-Reply-To: <20230203-alsa-pcm-test-card-thread-v1-1-59941640ebba@kernel.org> References: <20230203-alsa-pcm-test-card-thread-v1-1-59941640ebba@kernel.org> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/27.2 Mule/6.0 MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-BeenThere: alsa-devel@alsa-project.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Alsa-devel mailing list for ALSA developers - http://www.alsa-project.org" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: alsa-devel@alsa-project.org, linux-kernel@vger.kernel.org, Takashi Iwai , linux-kselftest@vger.kernel.org, Shuah Khan Errors-To: alsa-devel-bounces@alsa-project.org Sender: "Alsa-devel" On Fri, 03 Feb 2023 20:52:47 +0100, Mark Brown wrote: > > With each test taking 4 seconds the runtime of pcm-test can add up. Since > generally each card in the system is physically independent and will be > unaffected by what's going on with other cards we can mitigate this by > testing each card in parallel. Make a list of cards as we enumerate the > system and then start a thread for each, then join the threads to ensure > they have all finished. The threads each run the same tests we currently > run for each PCM on the card before exiting. > > The list of PCMs is kept global since it helps with global operations > like working out our planned number of tests and identifying missing PCMs > and it seemed neater to check for PCMs on the right card in the card > thread than make every PCM loop iterate over cards as well. > > We don't run per-PCM tests in parallel since in embedded systems it can > be the case that resources are shared between the PCMs and operations on > one PCM on a card may constrain what can be done on another PCM on the same > card leading to potentially unstable results. > > We use a mutex to ensure that the reporting of results is serialised and we > don't have issues with anything like the current test number, we could do > this in the kselftest framework but it seems like this might cause problems > for other tests that are doing lower level testing and building in > constrained environments such as nolibc so this seems more sensible. > > Note that the ordering of the tests can't be guaranteed as things stand, > this does not seem like a major problem since the numbering of tests often > changes as test programs are changed so results parsers are expected to > rely on the test name rather than the test numbers. We also now prefix the > machine generated test name when printing the description of the test since > this is logged before streaming starts. > > On my two card desktop system this reduces the overall runtime by a > third. > > Signed-off-by: Mark Brown Thanks, applied now. Takashi