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=-0.8 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=no 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 DF52BC33CAF for ; Thu, 16 Jan 2020 20:38:36 +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 6AFF72075B for ; Thu, 16 Jan 2020 20:38:36 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=alsa-project.org header.i=@alsa-project.org header.b="Thwe0ipi" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 6AFF72075B Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=suse.de Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=alsa-devel-bounces@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 B64FB17D4; Thu, 16 Jan 2020 21:37:44 +0100 (CET) DKIM-Filter: OpenDKIM Filter v2.11.0 alsa0.perex.cz B64FB17D4 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=alsa-project.org; s=default; t=1579207114; bh=eUlopDKBpBf+FR9/lWAXotpT9axoXR6eDj1350CZ1dg=; h=Date:From:To:In-Reply-To:References:Cc:Subject:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: From; b=Thwe0ipiVACA60SX1FAADuUKfvGLKNYPyJBs6pcKiHeWD7/7GL6vgQ6A9TaKz7Vxs 4Zndxbx8yDyIZ8pJJsu7ZJsmbDYxJuldDMbFr+XvjVo+YJqMrwlpQxJJs7D/K45gbe KnIrvB6gSD1LEEEjiQjcyIPX72kgy2cKE89xVYeM= Received: from alsa1.perex.cz (localhost.localdomain [127.0.0.1]) by alsa1.perex.cz (Postfix) with ESMTP id 37C8CF8014D; Thu, 16 Jan 2020 21:37:44 +0100 (CET) Received: by alsa1.perex.cz (Postfix, from userid 50401) id 2F31AF8014E; Thu, 16 Jan 2020 21:37:42 +0100 (CET) Received: from mx2.suse.de (mx2.suse.de [195.135.220.15]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by alsa1.perex.cz (Postfix) with ESMTPS id C5ACFF800B9 for ; Thu, 16 Jan 2020 21:37:39 +0100 (CET) DKIM-Filter: OpenDKIM Filter v2.11.0 alsa1.perex.cz C5ACFF800B9 X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.220.254]) by mx2.suse.de (Postfix) with ESMTP id 2FE6AC04B; Thu, 16 Jan 2020 20:37:38 +0000 (UTC) Date: Thu, 16 Jan 2020 21:37:37 +0100 Message-ID: From: Takashi Iwai To: Pierre-Louis Bossart In-Reply-To: References: <20200116045318.5498-1-yang.jie@linux.intel.com> <97bbe88d1a6b63fe8e9b02bf0c5ce4a80553c48d.camel@linux.intel.com> <3c0a0067043d614cd4491b28acf6d49640746b15.camel@linux.intel.com> <93ac843a-bad5-550e-f427-e2a94bd3e8ef@linux.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") Cc: Keyon Jie , "alsa-devel@alsa-project.org" , "Rajwa, Marcin" Subject: Re: [alsa-devel] [PATCH] ALSA: pcm: fix buffer_bytes max constrained by preallocated bytes issue 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: alsa-devel-bounces@alsa-project.org Sender: "Alsa-devel" On Thu, 16 Jan 2020 18:40:26 +0100, Pierre-Louis Bossart wrote: > > > >>>> So, do you suggest not doing preallocation(or calling it with 0 > >>>> size) for all > >>>> driver with TYPE_SG? I am fine if this is the recommended method, > >>>> I can try > >>>> this on SOF I2S platform to see if it can work as we required for > >>>> very large > >>>> buffer size. > >> > >> Keyon, for the rest of us to follow this patch, would you mind > >> clarifying what drives the need for a 'very large buffer size', and > >> what order of magnitude this very large size would be. > >> > >> FWIW, we've measured consistently on different Windows/Linux > >> platforms, maybe 10 years ago, that once you reach a buffer of 1s > >> (384 kB) the benefits from increasing that buffer size further are > >> marginal in terms of power consumption, and generate all kinds of > >> issues with volume updates and deferred routing changes. > >> > > We need bigger buffer on host side to compensate the wake up time > > from d0ix to d0 which takes ~2 seconds on my setup. So, wiith > > smaller buffer sizes like < 2 seconds we overwrite data since FW > > keeps copping while host doesn't read until its up and running > > again. > > Right, that's a valid case, but that's 256 kB, not 'very large' or > likely to ever trigger an OOM case. That size shouldn't matter, and would work even with the preallocation. My concern is that removing the limitation would allow the allocation of too large sizes. Even with dma_max limit, it can go up to 32MB physical pages per stream for HDA. Depending on the hardware setup, there can be a lot of streams assignment (e.g. HDMI codecs) and multiple codecs / controllers, and imagine that all those allocated pages are pinned and can't be swapped out... Takashi _______________________________________________ Alsa-devel mailing list Alsa-devel@alsa-project.org https://mailman.alsa-project.org/mailman/listinfo/alsa-devel