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 X-Spam-Level: X-Spam-Status: No, score=-8.8 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id E0760C432BE for ; Wed, 25 Aug 2021 06:15:33 +0000 (UTC) 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 mail.kernel.org (Postfix) with ESMTPS id 2AB9F613AD for ; Wed, 25 Aug 2021 06:15:31 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 2AB9F613AD Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=suse.de Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=alsa-project.org Received: from alsa1.perex.cz (alsa1.perex.cz [207.180.221.201]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by alsa0.perex.cz (Postfix) with ESMTPS id B4CCC1614; Wed, 25 Aug 2021 08:14:39 +0200 (CEST) DKIM-Filter: OpenDKIM Filter v2.11.0 alsa0.perex.cz B4CCC1614 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=alsa-project.org; s=default; t=1629872129; bh=32SttqUmC0bTEXy67UgCIFAbNXZIkdwfbD6B3RuKWtY=; h=Date:From:To:Subject:In-Reply-To:References:Cc:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: From; b=aEDUdfJHN11uXvEtFhGu5p+EicKuIQNXWwMJgp4NNjsoKRktUyDlQhqeFkaOLkulW XEtx1045lkQoAiNuZx9omcR0yS9IccQ2XHxG90rbQg9RmWdIz/1m/uZSXD2Rxsy9or 9tDzLVEP7Kzr/dvXjliQjCtV6HXTpUFp2TUeQ4ms= Received: from alsa1.perex.cz (localhost.localdomain [127.0.0.1]) by alsa1.perex.cz (Postfix) with ESMTP id E64A5F80171; Wed, 25 Aug 2021 08:14:38 +0200 (CEST) Received: by alsa1.perex.cz (Postfix, from userid 50401) id A5290F8020C; Wed, 25 Aug 2021 08:14:36 +0200 (CEST) Received: from smtp-out1.suse.de (smtp-out1.suse.de [195.135.220.28]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by alsa1.perex.cz (Postfix) with ESMTPS id 44F6FF800C9 for ; Wed, 25 Aug 2021 08:14:31 +0200 (CEST) DKIM-Filter: OpenDKIM Filter v2.11.0 alsa1.perex.cz 44F6FF800C9 Authentication-Results: alsa1.perex.cz; dkim=pass (1024-bit key) header.d=suse.de header.i=@suse.de header.b="fao/ANMP"; dkim=permerror (0-bit key) header.d=suse.de header.i=@suse.de header.b="6vdpzUvc" Received: from relay2.suse.de (relay2.suse.de [149.44.160.134]) by smtp-out1.suse.de (Postfix) with ESMTP id 0767F22086; Wed, 25 Aug 2021 06:14:25 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_rsa; t=1629872065; 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=qmmVCXmNCvtWG0FQQi2XPCH1qbLdvjT+J4eV9pRYcAc=; b=fao/ANMPXUVLNHSBkVyY/sZL/DSGHwDJnbZMGUM5T9LKTWTfw3/xJ9cdr0hQnqYuzUP8hj BOa0xOJH0d/l7BdWTcvnU2c/4qWSIzELcbn3sc9T8tBSKFE8R1d5aGIalWBfpTNkU7Zhwn YCzjl5QhE57o+wd+gnUowBLKa7KVKR0= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_ed25519; t=1629872065; 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=qmmVCXmNCvtWG0FQQi2XPCH1qbLdvjT+J4eV9pRYcAc=; b=6vdpzUvcOE4pBlgwnI89fWWO3FMA+BDbn4WNjvNZQrJNOdcj3DTU3eH6RGOZfUEtsfmVok w/MUolKWbFrFy4Cg== Received: from alsa1.suse.de (alsa1.suse.de [10.160.4.42]) by relay2.suse.de (Postfix) with ESMTP id DEE49A3B93; Wed, 25 Aug 2021 06:14:24 +0000 (UTC) Date: Wed, 25 Aug 2021 08:14:24 +0200 Message-ID: From: Takashi Iwai To: Jens Axboe Subject: Re: azx_get_pos_skl() induced system slowness In-Reply-To: <402d5952-3bf6-5c0d-5276-8367bfe1542a@kernel.dk> References: <402d5952-3bf6-5c0d-5276-8367bfe1542a@kernel.dk> 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 Cc: alsa-devel@alsa-project.org, tiwai@suse.com, kai.vehmanen@linux.intel.com X-BeenThere: alsa-devel@alsa-project.org X-Mailman-Version: 2.1.15 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: , Errors-To: alsa-devel-bounces@alsa-project.org Sender: "Alsa-devel" On Tue, 24 Aug 2021 19:38:08 +0200, Jens Axboe wrote: > > Hi, > > Got a new notebook recently, it's a Lenovo X1 Carbon 9th gen. Sound > works fine, but sometimes I get really stuttering playback from nestopia > and I finally decided to look into it. When this happens, > azx_get_pos_skl() is seemingly called a lot, at least it uses a ton of > CPU cycles. This comes and goes, sometimes 1 minute in between, > sometimes 2, and sometimes 30 seconds. > > If I comment out the udelay() in that function it does seems to be > noticeably better, though it's not a complete fix. I guess it just > reduces the pain of calling it so many times? > > This is running 5.14-rc7, but it's not a recent regression. > > Any clues as to what this might be? Are you using PulseAudio? Or pipewire? The former might cause lots of position update calls when the device doesn't give back the stable (or consistent) position report. The code there was borrowed from the ASoC Intel Skylake driver (sound/soc/intel/skylake/skl-pcm.c), and the same is also carried to the recent ASoC SOF HDA driver, too. As far as I understand from the comment, the udelay() itself could be reduced only for the case right after the interrupt wakeup. That is, a hackish patch like below might help. But, as far as I see with PulseAudio, it still results in a lot of register read -- so PA seems repeatedly reading the position. A better result (only from the CPU usage POV) could be gained on my machine by just switching to another position inquiry; namely, pass position_fix=1 option to snd-hda-intel module. But I checked this only for a short period, so am not sure about the long run. thanks, Takashi --- a/sound/pci/hda/hda_intel.c +++ b/sound/pci/hda/hda_intel.c @@ -614,6 +614,7 @@ static int azx_position_check(struct azx *chip, struct azx_dev *azx_dev) struct hda_intel *hda = container_of(chip, struct hda_intel, chip); int ok; + hda->in_irq_handling = 1; ok = azx_position_ok(chip, azx_dev); if (ok == 1) { azx_dev->irq_pending = 0; @@ -870,6 +871,8 @@ static unsigned int azx_skl_get_dpib_pos(struct azx *chip, /* get the current DMA position with correction on SKL+ chips */ static unsigned int azx_get_pos_skl(struct azx *chip, struct azx_dev *azx_dev) { + struct hda_intel *hda = container_of(chip, struct hda_intel, chip); + /* DPIB register gives a more accurate position for playback */ if (azx_dev->core.substream->stream == SNDRV_PCM_STREAM_PLAYBACK) return azx_skl_get_dpib_pos(chip, azx_dev); @@ -878,7 +881,10 @@ static unsigned int azx_get_pos_skl(struct azx *chip, struct azx_dev *azx_dev) * for the possible boundary overlap; the read of DPIB fetches the * actual posbuf */ - udelay(20); + if (hda->in_irq_handling) { + udelay(20); + hda->in_irq_handling = 0; + } azx_skl_get_dpib_pos(chip, azx_dev); return azx_get_pos_posbuf(chip, azx_dev); } diff --git a/sound/pci/hda/hda_intel.h b/sound/pci/hda/hda_intel.h index 3fb119f09040..79ea81535a00 100644 --- a/sound/pci/hda/hda_intel.h +++ b/sound/pci/hda/hda_intel.h @@ -22,6 +22,7 @@ struct hda_intel { /* extra flags */ unsigned int irq_pending_warned:1; unsigned int probe_continued:1; + unsigned int in_irq_handling:1; /* vga_switcheroo setup */ unsigned int use_vga_switcheroo:1;