Re: kern/56947: audio(4) may fail uobj allocation under VA fragmentation/preassure

[Tetsuya Isaki <isaki%pastel-flower.jp@localhost>]

Please try audio.c 1.135 (or later).
I have made two improvements on this revision.
- Memory reallocation should be reduced.
- Allocating uvm(9) defers until mmap is actually called.

If it doesn't improve your problem, then please show me
- dmesg (at least audio device, hardware device, and memory size).
- sysctl hw.pagesize
- sysctl hw.audio<N>.blk_ms
- what apps do you use?

> I added some instrumentation around audio_realloc_usrbuf and for a typical
> playback of a single song I get:
> 
> [ 26185.7526103] audio0: play format changing: 0/0/0/0 -> 8000/1/8/8
> [ 26185.7526103] audio0: block size changes from 0 to 512
> [ 26185.7526103] audio0: play format changing: 8000/1/8/8 -> 48000/7/16/16
> [ 26185.7526103] audio0: block size changes from 512 to 12288
> [ 26185.7626097] audio0: play format changing: 48000/7/16/16 -> 4800
> [ 26185.8226099] audio0: play format changing: 0/0/0/0 -> 8000/1/8/8
> [ 26185.8226099] audio0: block size changes from 0 to 512
> [ 26185.8226099] audio0: play format changing: 8000/1/8/8 -> 48000/7/16/16
> [ 26185.8226099] audio0: block size changes from 512 to 12288
> [ 26185.8226099] audio_free_usrbuf: freeing usrbuf
> 
> That is quite a bit of unecessary (re-)allocations.

I don't know details because I don't know where did you put this
message.  But it looks to me that two descriptors did the sequence
of open(it calls the initial AUDIO_SETINFO internally) and
AUDIO_SETINFO once respectively.

"#define AUDIO_DEBUG 2" (at sys/dev/audio/audio.c:242) will help.

>  a) could defer allocation untill the mmap actually happens (so the interim
>     variants like the default 8k ulaw that is never really used avoid it
>     completely)

"defer allocation until actual write (to avoid reallocating never-used
initial ulaw)" is not good idea.  Under this mechanism, even though you
issue AUDIO_SETINFO with the size which cannot be allocated, it will
succeed.  This will confuse users.

But "defer allocation until mmap" is interesting because only few apps
call mmap(2).

>  b) keep the uobj (and all allocations for it) around (i.e. not free
>     it on close) so we stick with a single 64k uobj for each audio
>     that is ever used at least once and never need to allocate anythin
>     on later open/uses

I disagree it as is.  It is technically possible but
- On modern machines, it's totally unnecessary mechanism despite
  the code is more complex.
- On ancient (small memory) machines, holding 64k at all times is
  acceptable?


Anyway, your suggestions inspired me much.  Thank you.
---
Tetsuya Isaki <isaki%pastel-flower.jp@localhost / isaki%NetBSD.org@localhost>