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 F0267C33CB1 for ; Thu, 16 Jan 2020 16:08:03 +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 7816F2077C for ; Thu, 16 Jan 2020 16:08:03 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=alsa-project.org header.i=@alsa-project.org header.b="raoX93Cf" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 7816F2077C 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 BB50F17B4; Thu, 16 Jan 2020 17:07:11 +0100 (CET) DKIM-Filter: OpenDKIM Filter v2.11.0 alsa0.perex.cz BB50F17B4 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=alsa-project.org; s=default; t=1579190881; bh=LG0ZpFpkzkgeInmTTMwdeT2yoy2Uro6cLFdyq6SxOn4=; h=Date:From:To:In-Reply-To:References:Cc:Subject:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: From; b=raoX93CfRuwQ+Z6wRXMqUe4VJ240s5gZ4lLpevjFjr3I0KONGOH1zxZh6GzKctWbJ JAEC2Jdn/a2wrLmy/YRzE/GkPZIXnVzbSAluJUsi38k5ApqbI4UVitz6qKO53vpu5U ANIMRP5xKivOJzznr7+kyR+d+gyxCiNGaZH84jbQ= Received: from alsa1.perex.cz (localhost.localdomain [127.0.0.1]) by alsa1.perex.cz (Postfix) with ESMTP id 34C51F8014D; Thu, 16 Jan 2020 17:07:11 +0100 (CET) Received: by alsa1.perex.cz (Postfix, from userid 50401) id 0B8BAF8014E; Thu, 16 Jan 2020 17:07:10 +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 59726F800B9 for ; Thu, 16 Jan 2020 17:07:03 +0100 (CET) DKIM-Filter: OpenDKIM Filter v2.11.0 alsa1.perex.cz 59726F800B9 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 C8A0FB272D; Thu, 16 Jan 2020 16:07:02 +0000 (UTC) Date: Thu, 16 Jan 2020 17:07:02 +0100 Message-ID: From: Takashi Iwai To: "Jie, Yang" In-Reply-To: References: <20200116045318.5498-1-yang.jie@linux.intel.com> <97bbe88d1a6b63fe8e9b02bf0c5ce4a80553c48d.camel@linux.intel.com> <3c0a0067043d614cd4491b28acf6d49640746b15.camel@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: "alsa-devel@alsa-project.org" , Keyon Jie 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 16:31:02 +0100, Jie, Yang wrote: > > > -----Original Message----- > > From: Jie, Yang > > Sent: Thursday, January 16, 2020 10:14 PM > > To: 'Takashi Iwai' ; Keyon Jie > > Cc: alsa-devel@alsa-project.org > > Subject: RE: [alsa-devel] [PATCH] ALSA: pcm: fix buffer_bytes max > > constrained by preallocated bytes issue > > > > > -----Original Message----- > > > From: Alsa-devel On Behalf Of > > > Takashi Iwai > > > Sent: Thursday, January 16, 2020 7:51 PM > > > To: Keyon Jie > > > Cc: alsa-devel@alsa-project.org > > > Subject: Re: [alsa-devel] [PATCH] ALSA: pcm: fix buffer_bytes max > > > constrained by preallocated bytes issue > > > > > > On Thu, 16 Jan 2020 12:25:38 +0100, > > > Keyon Jie wrote: > > > > > > > > On Thu, 2020-01-16 at 11:27 +0100, Takashi Iwai wrote: > > > > > On Thu, 16 Jan 2020 10:50:33 +0100, > > > > > > > > > > Oh, you're right, and I completely misread the patch. > > > > > > > > > > Now I took a coffee and can tell you the story behind the scene. > > > > > > > > > > I believe the current code is intentionally limiting the size to > > > > > the preallocated size. This limitation was brought for not trying > > > > > to allocate a larger buffer when the buffer has been preallocated. > > > > > In the past, most hardware allocated the continuous pages for a > > > > > buffer and the allocation of a large buffer fails quite likely. > > > > > This was the reason of the buffer preallocation. So, the driver > > > > > wanted to tell the user-space the limit. If user needs to have an > > > > > extra large buffer, they are supposed to fiddle with prealloc > > > > > procfs (either setting zero to clear the preallocation or setting > > > > > a large enough buffer beforehand). > > > > > > > > Thank you for the sharing, it is interesting and knowledge learned > > > > to me. > > > > > > > > > > > > > > For SG-buffers, though, limitation makes less sense than > > > > > continuous pages. e.g. a patch below removes the limitation for SG- > > buffers. > > > > > But changing this would definitely cause the behavior difference, > > > > > and I don't know whether it's a reasonable move -- I'm afraid that > > > > > apps would start hogging too much memory if the limitation is gone. > > > > > > > > I just went through all invoking to > > > > snd_pcm_lib_preallocate_pages*(), for those SNDRV_DMA_TYPE_DEV, > > some > > > > of them set the *size* equal to > > > the > > > > *max*, some set the *max* several times to the *size*, IMHO, the > > > > *max*s are matched to those hardware's limiatation, comparing to the > > > > *size*s, aren't they? > > > > > > > > In this case, I still think my patch hanle all > > > > TYPE_DEV/SNDRV_DMA_TYPE_DEV/TYPE_SG/SNDRV_DMA_TYPE_DEV > > > cases more > > > > gracefully, we will still take the limitation from the specific > > > > driver set, from the *max* param, and the test results looks very > > > > nice here, we will take what the user space wanted for buffer-bytes > > > > via aply exactly, as long as it is suitable for the interval and constraints. > > > > > > Well, I have a mixed feeling. Certainly we'd need some better way to > > > allow a larger buffer allocation, especially for HDA. OTOH, if the > > > buffer was preallocated, it's meant to be used actually. That's the > > > point of the hw_constraint setup. > > > > So if the buffer was preallocated, it won't be re-allocated at hw_params() > > stage, is this conflict with the re-allocate logic in hw_params()? > > > > > > > > And now thinking again after another cup of coffee, I wonder why we do > > > preallocate for HDA at all. For HD-audio, the allocation of any large > > > buffer would succeed very likely because of SG-buffer. > > > > > > So, just setting 0 to the preallocation size (but keeping else) would work, > > e.g. > > > something like below? The help text needs adjustment, but you can see > > > the rough idea. > > > > 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. > > Tried and found setting 0 size for preallocation doesn't work for me, I have > even tried to setting the size as big as the max(which the user space may > require for buffer-bytes), it still doesn't work for me. How did you test it? I quickly checked now on my machine, and it seems working... # echo 1024 > /proc/asound/card0/pcm0p/sub0/prealloc # aplay -Dhw:0 -v --buffer-size=1048576 foo.wav Hardware PCM card 0 'HDA Intel PCH' device 0 subdevice 0 Its setup is: stream : PLAYBACK .... buffer_size : 262144 # echo 0 > /proc/asound/card0/pcm0p/sub0/prealloc # aplay -Dhw:0 -v --buffer-size=1048576 foo.wav Hardware PCM card 0 'HDA Intel PCH' device 0 subdevice 0 Its setup is: stream : PLAYBACK .... buffer_size : 1048576 Takashi _______________________________________________ Alsa-devel mailing list Alsa-devel@alsa-project.org https://mailman.alsa-project.org/mailman/listinfo/alsa-devel