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@xxxxxxxxxxxxxxxx
https://mailman.alsa-project.org/mailman/listinfo/alsa-devel
_______________________________________________
Alsa-devel mailing list
Alsa-devel@xxxxxxxxxxxxxxxx
https://mailman.alsa-project.org/mailman/listinfo/alsa-devel
