svn commit: r274017 - head/sys/kern

[Hans Petter Selasky]

On 11/03/14 10:08, Mateusz Guzik wrote:
> On Mon, Nov 03, 2014 at 04:21:02PM +0800, Julian Elischer wrote:
>> On 11/3/14, 3:46 PM, Mateusz Guzik wrote:
>>> Author: mjg
>>> Date: Mon Nov  3 07:46:51 2014
>>> New Revision: 274017
>>> URL: https://svnweb.freebsd.org/changeset/base/274017
>>>
>>> Log:
>>>    Provide an on-stack temporary buffer for small ioctl requests.
>> I'm not sure I like this. We don't know how many more levels
>> of stack may be needed.
>> I know that machines are getting faster with more memory,
>> but the current move towards bloating out the
>> worries me.  we started out with a single page of stack (SHARED
>> with the U-area!). I think we are now at several pages.. I forget, is
>> it 8?
>> I'm open to being persuaded but I think we need to have a discussion
>> about stack usage. We used to say that anything greater that, say
>> 64 bytes should probably be allocated.
>>
>
> Depends on the arch, 2 on arm and mips, 4 on the rest. Roughly speaking.
>
> If 128 in ioctl is really such a big concern I'm happy to make it
> smaller, but I do prefer to have a buffer covering some stuff.
>
> Just booting the system gives:
> size	occurences
> 4	  118
> 8	  60
> 16	   3
> 20	   8
> 24	   33
> 32	   127
> 36	   8
> 40	   16
> 44	   268
> 48	   278
> 68	   1
> 72	   31
> 80	   8
> 192	    1
> 236	    55
> 256	    1
> 288	    22
> 817	    8
>
> Building the kernel gives me over 38000 occurences of size 44 (separate question
> is what is that ioctl and is it really necessary to call it).
>
> That said, maybe 128 was indeed too big. 64 sounds like a nice round number to me.
>

Hi,

64 will work for USB and CUSE4BSD too, which cause thousands of such 
small memory allocations inside IOCTLs when streaming TV and such.

Mateusz: Maybe you have a USB device laying around? Goto 
src/tools/tools/usbtest, build and install, select a USB device and run 
the string descriptor test (not harmful). Then watch the memory statistics!

--HPS