Re: [alsa-devel] [PATCH] ALSA: pcm: fix buffer_bytes max constrained by preallocated bytes issue

[Takashi Iwai <tiwai@suse.de>]

On Fri, 17 Jan 2020 11:13:31 +0100,
Keyon Jie wrote:
> 
> 
> 
> On 2020/1/17 下午3:57, Takashi Iwai wrote:
> > On Fri, 17 Jan 2020 06:30:18 +0100,
> > Keyon Jie wrote:
> >>
> >> On 2020/1/17 上午4:37, Takashi Iwai wrote:
> >>
> >> 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?
> >
> > No, in general, all sound hardware buffers are pinned.
> 
> Sorry, I must have been wrong here, what I was focusing on is those
> allocated SG DMA buffers, I am not sure if they are those you called
> "hardware buffers" here.
> 
> My understanding was like this:
> 
> 1. in pcm_new() stage, the device PCM driver should call
> snd_pcm_lib_preallocate_pages()->
> 	snd_pcm_lib_preallocate_pages()->
> 		preallocate_pcm_pages()
> and then the substream->dma_buffer is initialized with the
> preallocated buffer.
> 
> 2. in pcm_open() stage, the device PCM driver should call
> snd_pcm_lib_malloc_pages()->
> 	snd_dma_alloc_pages() //if we need to reallocate bigger
> buffer. *The substream->dma_buffer won't be freed, Takashi, this is
> what I thought you named "pinned" buffer.* And those reallocated
> bigger buffer via snd_dma_alloc_pages() will be freed at pcm_close()
> per my understanding?

What I meant as "pinned" is that the pages are not swapped out by
swapper process like the user-space or anonymous pages.
So if you open all streams (say 16 streams) on a machine with 32MB
buffers, it'll cost a half GB.  And, we have no restriction about
which user may do it, so all normal users who have the access to the
sound device can consume a half GB kernel space pages easily.  For a
big server it's no problem, but for a small system, it's costing.


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