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 gabe.freedesktop.org (gabe.freedesktop.org [131.252.210.177]) (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 3D2ABC433F5 for ; Fri, 25 Feb 2022 11:42:55 +0000 (UTC) Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id 722F710E976; Fri, 25 Feb 2022 11:42:54 +0000 (UTC) Received: from smtp-out2.suse.de (smtp-out2.suse.de [195.135.220.29]) by gabe.freedesktop.org (Postfix) with ESMTPS id E4C1110E976; Fri, 25 Feb 2022 11:42:52 +0000 (UTC) Received: from relay2.suse.de (relay2.suse.de [149.44.160.134]) by smtp-out2.suse.de (Postfix) with ESMTP id 4C1341F383; Fri, 25 Feb 2022 11:42:51 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_rsa; t=1645789371; 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=YaHNmOiZFxQKjStBsK7jODDFVyoFZ98HK7HnAlWrbHk=; b=Rzzl/hyejA45UjLWfiwVgE1YevkTIJoh88Nab1iPzzPwWK4M8XQXtYwi7sdY/3bPrFKGao /28/sbhfPhuCZrvwfyYn0ma04tKs9sxbwOICsJ1YX1bbtzLQ597taHDYGCt23T7XtwBGVP P0osU284sGlV6xi0kW5jK++El2S9CuA= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_ed25519; t=1645789371; 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=YaHNmOiZFxQKjStBsK7jODDFVyoFZ98HK7HnAlWrbHk=; b=1VjWWiMJVhwe5SlJzsom7EqugwAQNqSfo++vIZvi+ow3dZzf0ck0EN1m+5p2TpXj6iehJz JANdI5UMaeXE0kAg== Received: from alsa1.suse.de (alsa1.suse.de [10.160.4.42]) by relay2.suse.de (Postfix) with ESMTP id 3DD19A3B84; Fri, 25 Feb 2022 11:42:51 +0000 (UTC) Date: Fri, 25 Feb 2022 12:42:51 +0100 Message-ID: From: Takashi Iwai To: Kai Vehmanen In-Reply-To: References: <20220223195203.13708-1-ramalingam.c@intel.com> <20220223195203.13708-3-ramalingam.c@intel.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI/1.14.6 (Maruoka) FLIM/1.14.9 (=?UTF-8?B?R29qxY0=?=) APEL/10.8 Emacs/25.3 (x86_64-suse-linux-gnu) MULE/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Subject: Re: [Intel-gfx] [PATCH 2/2] hda/i915: split the wait for the component binding X-BeenThere: intel-gfx@lists.freedesktop.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Intel graphics driver community testing & development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Kai Vehmanen , intel-gfx , lucas.demarchi@intel.com, dri-devel , Takashi Iwai Errors-To: intel-gfx-bounces@lists.freedesktop.org Sender: "Intel-gfx" On Thu, 24 Feb 2022 17:34:54 +0100, Kai Vehmanen wrote: > > Hi, > > On Thu, 24 Feb 2022, Ramalingam C wrote: > > > Split the wait for component binding from i915 in multiples of > > sysctl_hung_task_timeout_secs. This helps to avoid the possible kworker > > thread hung detection given below. > > while I understand the problem, I'm not sure whether a simpler option > should be chosen. Maybe just split the wait_for_completion_timeout() > into small 5sec iterations, without consulting value of hung_task_timeout. > This would seem unligned with more mainstream use of > wait_for_completion_timeout() in kernel and still do the job. > > I'll loop in Takashi here as well. Basicly the 60 sec timeout in > hda/hdac_i915.c is getting caught by hung_task_detection logic in builds > where the hung_task_timeout is below 60secs. > > I have a patch that tries to avoid hitting the timeout in some of the more > common cases: > "ALSA: hda/i915 - skip acomp init if no matching display" > https://lists.freedesktop.org/archives/intel-gfx-trybot/2022-February/128278.html > ... but we'll still be stuck with some configurations where the timeout > will be hit. And above needs careful testing. > > One logic comment below as well, but I'll quote the whole patch to give > context to Takashi. I agree with Kai, we can just make the wait_for_completion_timeout() split in a loop independently from hung_task_timeout. It's simpler, less error-prone. thanks, Takashi