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 7F715C33CB1 for ; Thu, 16 Jan 2020 15:46:19 +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 0A1B4206D9 for ; Thu, 16 Jan 2020 15:46:19 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=alsa-project.org header.i=@alsa-project.org header.b="PI5cNq32" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 0A1B4206D9 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 513CB17BD; Thu, 16 Jan 2020 16:45:27 +0100 (CET) DKIM-Filter: OpenDKIM Filter v2.11.0 alsa0.perex.cz 513CB17BD DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=alsa-project.org; s=default; t=1579189577; bh=FakJ7srfSmIU53snmh4eQnRlfSzmg6Fc7cl76UIMZ+E=; h=Date:From:To:In-Reply-To:References:Cc:Subject:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: From; b=PI5cNq32GUS+sBfuSfh2fcSKr6b/NBX+FztlR5y409ToT3PVfh1iypewFfzKWhhCl Fw5yqEuFlUPpa5UE28ZI/xTm1HT+EBtLz5m946O2cgW00Ouyr6tI8IsdDyWnDZUbZb PZxH20XbZiG2nav9L+hQ0GA7rdFIc8SwLgwM8QSc= Received: from alsa1.perex.cz (localhost.localdomain [127.0.0.1]) by alsa1.perex.cz (Postfix) with ESMTP id B3E22F8014D; Thu, 16 Jan 2020 16:45:26 +0100 (CET) Received: by alsa1.perex.cz (Postfix, from userid 50401) id 7F533F8014E; Thu, 16 Jan 2020 16:45:24 +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 528C5F80086 for ; Thu, 16 Jan 2020 16:45:17 +0100 (CET) DKIM-Filter: OpenDKIM Filter v2.11.0 alsa1.perex.cz 528C5F80086 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 10296B1EB9; Thu, 16 Jan 2020 15:45:16 +0000 (UTC) Date: Thu, 16 Jan 2020 16:45:16 +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 15:14:28 +0100, Jie, Yang wrote: > > > -----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()? If a larger buffer than the preallocated one is requested, the PCM core tries to allocate another buffer while the preallocated one remains kept untouched. It's because such a larger allocation is supposed to be one-off thing. Normal usages should fit with the preallocated buffer size. That said, if a larger buffer is required too frequently, it makes no sense to keep the preallocation. Or, preallocate larger buffers instead. > > 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. This really depends on the use case, and I'm not yet sure whether no preallocation is really recommended or not. Without preallocation, each PCM open is involved with a large amount of page allocations, and it makes easier for users to hog resources more easily. It'll use vmalloc addresses that aren't unlimited, and may trigger OOM easily. thanks, Takashi _______________________________________________ Alsa-devel mailing list Alsa-devel@alsa-project.org https://mailman.alsa-project.org/mailman/listinfo/alsa-devel