From owner-svn-src-head@FreeBSD.ORG Mon Nov 3 09:20:25 2014 Return-Path: Delivered-To: svn-src-head@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 3B499891; Mon, 3 Nov 2014 09:20:25 +0000 (UTC) Received: from mail.turbocat.net (heidi.turbocat.net [88.198.202.214]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id ECA2D228; Mon, 3 Nov 2014 09:20:24 +0000 (UTC) Received: from laptop015.home.selasky.org (cm-176.74.213.204.customer.telag.net [176.74.213.204]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.turbocat.net (Postfix) with ESMTPSA id 2E21F1FE022; Mon, 3 Nov 2014 10:20:22 +0100 (CET) Message-ID: <545748E1.5050100@selasky.org> Date: Mon, 03 Nov 2014 10:20:33 +0100 From: Hans Petter Selasky User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.1.2 MIME-Version: 1.0 To: Mateusz Guzik , Julian Elischer Subject: Re: svn commit: r274017 - head/sys/kern References: <201411030746.sA37kpPu037113@svn.freebsd.org> <54573AEE.9010602@freebsd.org> <20141103090800.GG29497@dft-labs.eu> In-Reply-To: <20141103090800.GG29497@dft-labs.eu> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Cc: svn-src-head@freebsd.org, svn-src-all@freebsd.org, src-committers@freebsd.org, Mateusz Guzik X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: SVN commit messages for the src tree for head/-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Nov 2014 09:20:25 -0000 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