From owner-svn-src-head@FreeBSD.ORG Mon Nov 3 10:08:57 2014 Return-Path: Delivered-To: svn-src-head@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 01427936 for ; Mon, 3 Nov 2014 10:08:56 +0000 (UTC) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 9706B8DE for ; Mon, 3 Nov 2014 10:08:56 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.9/8.14.9) with ESMTP id sA3A8ltk011468 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 3 Nov 2014 12:08:47 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.9.2 kib.kiev.ua sA3A8ltk011468 Received: (from kostik@localhost) by tom.home (8.14.9/8.14.9/Submit) id sA3A8lPp011467; Mon, 3 Nov 2014 12:08:47 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Mon, 3 Nov 2014 12:08:47 +0200 From: Konstantin Belousov To: Mateusz Guzik Subject: Re: svn commit: r274017 - head/sys/kern Message-ID: <20141103100847.GK53947@kib.kiev.ua> References: <201411030746.sA37kpPu037113@svn.freebsd.org> <54573AEE.9010602@freebsd.org> <54573B87.7000801@freebsd.org> <54573CD2.1000702@selasky.org> <20141103092132.GH29497@dft-labs.eu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20141103092132.GH29497@dft-labs.eu> User-Agent: Mutt/1.5.23 (2014-03-12) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.0 X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on tom.home Cc: Hans Petter Selasky , src-committers@freebsd.org, Mateusz Guzik , jmallett@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org, Julian Elischer 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 10:08:57 -0000 On Mon, Nov 03, 2014 at 10:21:32AM +0100, Mateusz Guzik wrote: > On Mon, Nov 03, 2014 at 09:29:06AM +0100, Hans Petter Selasky wrote: > > On 11/03/14 09:23, Julian Elischer wrote: > > >On 11/3/14, 4:21 PM, 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 > > >... "bloating out the stack" ... > > >>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. > > >> > > > > Hi, > > > > I think this patch can give a benefit for the USB stack and CUSE4BSD, > > because it does frequent IOCTLs. Regarding the stack usage, maybe > > this general purpose optimisation can be allocated from the thread > > structure? > > > > I was considering something like that. The idea is that frequently > allocating threads could allocate, say, 1KB from malloc and use that > to satisfy their needs. This definitely helps offenders with longer > lifespan, but does not help short-lived ones. Allocating 1KB by malloc() consumes that memory for the whole lifespan of the thread, and the memory sit unused except some short periods. For the stack allocation which you did, at least the memory is reused when needed (i.e. when syscalls other than ioctl(2) are executing). That said, you could slightly improve the code by using __builtin_alloc() instead of unconditionally reserving memory on stack. This will simultaneosly reduce the stack usage, since you only allocate as much as needed, and also avoid stack space waste when fallback to malloc() is required anyway. > > That said, maybe I'm over-engineering this, but for cases where increased > stack usage is undersirable we could have a malloc wrapper for use by > code which knows it allocates stuff just to free it after the request. > > When it concludes a threshold is reached, allocates some memory and > keeps it around. It can easily support multiple "allocations" from that > buffer and fallbak to malloc if it runs out of space. > > -- > Mateusz Guzik