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
_______________________________________________
svn-src-head@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
