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

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

The following reply was made to PR kern/56947; it has been noted by GNATS.

From: Tetsuya Isaki <isaki%pastel-flower.jp@localhost>
To: gnats-bugs%netbsd.org@localhost
Cc: kern-bug-people%netbsd.org@localhost,
	gnats-admin%netbsd.org@localhost,
	netbsd-bugs%netbsd.org@localhost
Subject: Re: kern/56947: audio(4) may fail uobj allocation under VA fragmentation/preassure
Date: Sat, 13 Aug 2022 16:03:07 +0900

 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>