From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from [140.186.70.92] (port=60966 helo=eggs.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1PvBfr-0005k3-Bg
	for qemu-devel@nongnu.org; Thu, 03 Mar 2011 11:46:52 -0500
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <froydnj@codesourcery.com>) id 1PvBfm-0001Ul-8Q
	for qemu-devel@nongnu.org; Thu, 03 Mar 2011 11:46:47 -0500
Received: from mail.codesourcery.com ([38.113.113.100]:34168)
	by eggs.gnu.org with esmtp (Exim 4.71)
	(envelope-from <froydnj@codesourcery.com>) id 1PvBfl-0001UV-VG
	for qemu-devel@nongnu.org; Thu, 03 Mar 2011 11:46:42 -0500
Date: Thu, 3 Mar 2011 08:46:40 -0800
From: Nathan Froyd <froydnj@codesourcery.com>
Subject: Re: [Qemu-devel] [PATCH] linux-user: bigger default stack
Message-ID: <20110303164639.GB23686@codesourcery.com>
References: <20110303153737.GA23633@afflict.kos.to>
	<20110303154626.GA23686@codesourcery.com>
	<20110303161549.GA27102@afflict.kos.to>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20110303161549.GA27102@afflict.kos.to>
List-Id: qemu-devel.nongnu.org
List-Unsubscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.nongnu.org/archive/html/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: Riku Voipio <riku.voipio@iki.fi>
Cc: qemu-devel@nongnu.org

On Thu, Mar 03, 2011 at 06:15:49PM +0200, Riku Voipio wrote:
> On Thu, Mar 03, 2011 at 07:46:27AM -0800, Nathan Froyd wrote:
> > On Thu, Mar 03, 2011 at 05:37:37PM +0200, Riku Voipio wrote:
> > > PTHREAD_STACK_MIN (16KB) is somewhat inadequate for a new stack. follow
> > > the pthread_create defaults, ie setting to RLIMIT_STACK or if unlimited
> > > to 2MB.
>  
> > For what sort oof cases is it inadequate?  This stack is just for QEMU's
> > usage and QEMU shouldn't be using very much.  
> 
> QEMU linux-user calls glibc functions which, while usually very conservative
> with memory usage, are not guaranteed not take less than 10KB (at do_syscall
> we are already around 5 functions deep).

Bleh.  OK, so it needs to be increased.  Could we get by with somewhat
less (256K?), to try and maximize the number of threads we can
potentially run?  Maybe it doesn't matter (people creating thousands of
simultaneous threads inside QEMU have other problems...), but not
gratuitously wasting memory would be good.

-Nathan