All of lore.kernel.org
 help / color / mirror / Atom feed
From: Keyon Jie <yang.jie@linux.intel.com>
To: Takashi Iwai <tiwai@suse.de>,
	Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Cc: "alsa-devel@alsa-project.org" <alsa-devel@alsa-project.org>,
	"Rajwa, Marcin" <marcin.rajwa@linux.intel.com>
Subject: Re: [alsa-devel] [PATCH] ALSA: pcm: fix buffer_bytes max constrained by preallocated bytes issue
Date: Fri, 17 Jan 2020 13:30:18 +0800	[thread overview]
Message-ID: <a1b549b7-a902-b2ee-e2e4-53f73893def3@linux.intel.com> (raw)
In-Reply-To: <s5h5zhbp27i.wl-tiwai@suse.de>

On 2020/1/17 上午4:37, Takashi Iwai wrote:
> 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...

Hi Takashi, I get your concern here, but if we switch to use dma_max 
limit, we won't change the preallocated buffer, it will be still 64KB 
for each stream, user space can ask for re-allocate buffer for each 
stream up to 32MB, but those pinned and can't be swapped out ones are 
the 64KB preallocated ones only, am I wrong?

Thanks,
~Keyon

> 
> 
> Takashi
> _______________________________________________
> Alsa-devel mailing list
> Alsa-devel@alsa-project.org
> https://mailman.alsa-project.org/mailman/listinfo/alsa-devel
> 
_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
https://mailman.alsa-project.org/mailman/listinfo/alsa-devel

  reply	other threads:[~2020-01-17  5:30 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-01-16  4:53 [alsa-devel] [PATCH] ALSA: pcm: fix buffer_bytes max constrained by preallocated bytes issue Keyon Jie
2020-01-16  7:15 ` Takashi Iwai
2020-01-16  9:50   ` Keyon Jie
2020-01-16 10:27     ` Takashi Iwai
2020-01-16 11:25       ` Keyon Jie
2020-01-16 11:50         ` Takashi Iwai
2020-01-16 14:14           ` Jie, Yang
2020-01-16 15:31             ` Jie, Yang
2020-01-16 16:07               ` Takashi Iwai
2020-01-16 16:39               ` Pierre-Louis Bossart
2020-01-16 17:25                 ` Rajwa, Marcin
2020-01-16 17:40                   ` Pierre-Louis Bossart
2020-01-16 20:37                     ` Takashi Iwai
2020-01-17  5:30                       ` Keyon Jie [this message]
2020-01-17  7:57                         ` Takashi Iwai
2020-01-17 10:13                           ` Keyon Jie
2020-01-17 10:30                             ` Takashi Iwai
2020-01-17 10:56                               ` Keyon Jie
2020-01-17 11:15                                 ` Takashi Iwai
2020-01-17  5:37                     ` Keyon Jie
2020-01-17  8:00                       ` Takashi Iwai
2020-01-17 10:43                         ` Keyon Jie
2020-01-17 11:12                           ` Takashi Iwai
2020-01-19  3:52                             ` Keyon Jie
2020-01-19  7:09                               ` Takashi Iwai
2020-01-19  8:11                                 ` Keyon Jie
2020-01-19  9:04                                   ` Takashi Iwai
2020-01-19 10:14                                     ` Keyon Jie
2020-01-19 10:43                                       ` Takashi Iwai
2020-01-20  2:23                                         ` Keyon Jie
2020-01-16 15:45             ` Takashi Iwai

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=a1b549b7-a902-b2ee-e2e4-53f73893def3@linux.intel.com \
    --to=yang.jie@linux.intel.com \
    --cc=alsa-devel@alsa-project.org \
    --cc=marcin.rajwa@linux.intel.com \
    --cc=pierre-louis.bossart@linux.intel.com \
    --cc=tiwai@suse.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.