From owner-svn-src-all@FreeBSD.ORG Mon Nov 3 09:21:38 2014 Return-Path: Delivered-To: svn-src-all@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 531F79D0; Mon, 3 Nov 2014 09:21:38 +0000 (UTC) Received: from mail-wg0-x233.google.com (mail-wg0-x233.google.com [IPv6:2a00:1450:400c:c00::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 24DFF231; Mon, 3 Nov 2014 09:21:36 +0000 (UTC) Received: by mail-wg0-f51.google.com with SMTP id l18so10487778wgh.38 for ; Mon, 03 Nov 2014 01:21:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=sH+q1mEaESdYYMhbPPAc14MoHSShL8XUpYQXIsnCP1o=; b=XqVILHtphyZ9kpl8DKPjLv8pR9Fj6BVUjHAJy4RI0EaJ5+E+48NibY9XLEc+JoQtrT tsp+ER+BvMBd8jailV4SnW8p9GpZGG8EZzPqgnUaYhJp2i5QyZs9JqL/v4dME7973mfR 3eCh5RD/MlJcLdOyjQ91bdjmb1c1qROublknPJdXw0iaTWUZCWxI9krM1UyAfXtWhfEC NM5C2jbn+SjbxOGzcrEn5KMyaYUlle1nyFmOpSGNaaSpoobKhwyTBNNmp3vDwLhigOIb VXH00eRIK9FGlTyB29pdjAl/3lNzELuU/sZTFIt1cG+jCgiMmfH0qMdmpxHblTiv2tV9 PYnA== X-Received: by 10.180.102.135 with SMTP id fo7mr15096448wib.79.1415006495375; Mon, 03 Nov 2014 01:21:35 -0800 (PST) Received: from dft-labs.eu (n1x0n-1-pt.tunnel.tserv5.lon1.ipv6.he.net. [2001:470:1f08:1f7::2]) by mx.google.com with ESMTPSA id u13sm8034938wiv.10.2014.11.03.01.21.34 for (version=TLSv1.2 cipher=RC4-SHA bits=128/128); Mon, 03 Nov 2014 01:21:34 -0800 (PST) Date: Mon, 3 Nov 2014 10:21:32 +0100 From: Mateusz Guzik To: Hans Petter Selasky Subject: Re: svn commit: r274017 - head/sys/kern Message-ID: <20141103092132.GH29497@dft-labs.eu> References: <201411030746.sA37kpPu037113@svn.freebsd.org> <54573AEE.9010602@freebsd.org> <54573B87.7000801@freebsd.org> <54573CD2.1000702@selasky.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <54573CD2.1000702@selasky.org> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: 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-all@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Nov 2014 09:21:38 -0000 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. 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