All of lore.kernel.org
 help / color / mirror / Atom feed
From: Takashi Iwai <tiwai@suse.de>
To: Mark Brown <broonie@kernel.org>
Cc: Jaroslav Kysela <perex@perex.cz>, Takashi Iwai <tiwai@suse.com>,
	Shuah Khan <shuah@kernel.org>,
	alsa-devel@alsa-project.org, linux-kselftest@vger.kernel.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH] kselftest/alsa: Run PCM tests for multiple cards in parallel
Date: Sat, 04 Feb 2023 09:37:16 +0100	[thread overview]
Message-ID: <877cwxn7wj.wl-tiwai@suse.de> (raw)
In-Reply-To: <20230203-alsa-pcm-test-card-thread-v1-1-59941640ebba@kernel.org>

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 <broonie@kernel.org>

Thanks, applied now.


Takashi

WARNING: multiple messages have this Message-ID (diff)
From: Takashi Iwai <tiwai@suse.de>
To: Mark Brown <broonie@kernel.org>
Cc: alsa-devel@alsa-project.org, linux-kernel@vger.kernel.org,
	Takashi Iwai <tiwai@suse.com>,
	linux-kselftest@vger.kernel.org, Shuah Khan <shuah@kernel.org>
Subject: Re: [PATCH] kselftest/alsa: Run PCM tests for multiple cards in parallel
Date: Sat, 04 Feb 2023 09:37:16 +0100	[thread overview]
Message-ID: <877cwxn7wj.wl-tiwai@suse.de> (raw)
In-Reply-To: <20230203-alsa-pcm-test-card-thread-v1-1-59941640ebba@kernel.org>

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 <broonie@kernel.org>

Thanks, applied now.


Takashi

  reply	other threads:[~2023-02-04  8:37 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-02-03 19:52 [PATCH] kselftest/alsa: Run PCM tests for multiple cards in parallel Mark Brown
2023-02-03 19:52 ` Mark Brown
2023-02-04  8:37 ` Takashi Iwai [this message]
2023-02-04  8:37   ` Takashi Iwai

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=877cwxn7wj.wl-tiwai@suse.de \
    --to=tiwai@suse.de \
    --cc=alsa-devel@alsa-project.org \
    --cc=broonie@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-kselftest@vger.kernel.org \
    --cc=perex@perex.cz \
    --cc=shuah@kernel.org \
    --cc=tiwai@suse.com \
    /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.