Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Date:   Wed, 21 Jun 2023 18:34:22 +0200
Message-ID: <87352krcz5.wl-tiwai@suse.de>
From:   Takashi Iwai <tiwai@suse.de>
To:     =?ISO-8859-1?Q?=22N=EDcolas_F=2E_R=2E_A=2E=22?= Prado 
        <nfraprado@collabora.com>
Cc:     Mark Brown <broonie@kernel.org>, Jaroslav Kysela <perex@perex.cz>,
        kernel@collabora.com,
        AngeloGioacchino Del Regno 
        <angelogioacchino.delregno@collabora.com>,
        Shuah Khan <shuah@kernel.org>, Takashi Iwai <tiwai@suse.com>,
        alsa-devel@alsa-project.org, linux-kernel@vger.kernel.org,
        linux-kselftest@vger.kernel.org
Subject: Re: [PATCH 2/2] kselftest/alsa: pcm-test: Decrease stream duration from 4 to 2 seconds
In-Reply-To: <5c2d5213-5299-44f1-9611-26002c8a5d3a@notapiano>
References: <20230620220839.2215057-1-nfraprado@collabora.com>
        <20230620220839.2215057-3-nfraprado@collabora.com>
        <33bea0d3-b8dd-4936-812e-392166df4437@sirena.org.uk>
        <443f697b-fecf-6e8e-0b76-65257aff7da8@perex.cz>
        <9069ad0c-d166-4620-a3de-a36ab233cab0@sirena.org.uk>
        <5c2d5213-5299-44f1-9611-26002c8a5d3a@notapiano>
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=ISO-8859-1
Content-Transfer-Encoding: 8bit
Precedence: bulk

On Wed, 21 Jun 2023 18:03:22 +0200,
N?colas F. R. A. Prado wrote:
> 
> On Wed, Jun 21, 2023 at 03:39:12PM +0100, Mark Brown wrote:
> > On Wed, Jun 21, 2023 at 04:08:47PM +0200, Jaroslav Kysela wrote:
> > 
> > > I think that the problem is somewhere else here. The overall test timeout
> > > should be calculated dynamically. All tests may be queried for the maximal
> > > expected interval based on the hardware/software capabilities. It's a bit
> > > pitfall to have a fixed time limit where the realtime tests depend on the
> > > number of devices.
> > 
> > I tend to agree here, unfortunately Shuah hasn't responded to queries
> > from N?colas about this which I imagine is what inspired this patch.  We
> > also have problems with mixer-test on one of the Dialog CODECs with a
> > couple of 64k value controls and no cache only mode.
> 
> Yes, exactly. I've tried increasing the timeout for this test to a larger fixed
> value previously, and later asked for more information on how to deal with the
> kselftest timeout. [1]
> 
> Since I didn't hear back, I thought this patch would be a way to at least
> mitigate the issue for now, without limiting the test coverage, which was a
> concern with having limited scopes for the test.
> 
> I've just noticed that in the mean time a way to override the timeout when
> running kselftest has been introduced [2], so I suppose we could use that to
> work around the timeout limitation in CI systems and be able to run through
> completion on the different hardware at the lab. But I still believe, like you
> do, that calculating the timeout at runtime based on the hardware would make
> much more sense, though if there's such a desire to keep kselftests under the
> 45s mark, I'm not sure if it would be acceptable.
> 
> [1] https://lore.kernel.org/all/5302e70d-cb58-4e70-b44f-ff81b138a2e1@notapiano/
> [2] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=f6a01213e3f8

So, we're back to square...  Unless anyone has a strong objection, I'm
inclined to take this as a workaround for 6.5 for now, as the merge
window deadline is coming.  We can improve things at the same time for
the future kernel, too.


thanks,

Takashi