Date: Mon, 03 Nov 2014 10:20:33 +0100 From: Hans Petter Selasky <hps@selasky.org> To: Mateusz Guzik <mjguzik@gmail.com>, Julian Elischer <julian@freebsd.org> Cc: svn-src-head@freebsd.org, svn-src-all@freebsd.org, src-committers@freebsd.org, Mateusz Guzik <mjg@FreeBSD.org> Subject: Re: svn commit: r274017 - head/sys/kern Message-ID: <545748E1.5050100@selasky.org> In-Reply-To: <20141103090800.GG29497@dft-labs.eu> References: <201411030746.sA37kpPu037113@svn.freebsd.org> <54573AEE.9010602@freebsd.org> <20141103090800.GG29497@dft-labs.eu>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?545748E1.5050100>