From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from [140.186.70.92] (port=33295 helo=eggs.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1PvQAz-0003J9-0j
	for qemu-devel@nongnu.org; Fri, 04 Mar 2011 03:15:53 -0500
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <nchip@afflict.kos.to>) id 1PvQAx-0007VZ-UR
	for qemu-devel@nongnu.org; Fri, 04 Mar 2011 03:15:52 -0500
Received: from afflict.kos.to ([92.243.29.197]:57636)
	by eggs.gnu.org with esmtp (Exim 4.71)
	(envelope-from <nchip@afflict.kos.to>) id 1PvQAx-0007VV-O7
	for qemu-devel@nongnu.org; Fri, 04 Mar 2011 03:15:51 -0500
Date: Fri, 4 Mar 2011 10:15:50 +0200
From: Riku Voipio <riku.voipio@iki.fi>
Subject: Re: [Qemu-devel] [PATCH] linux-user: bigger default stack
Message-ID: <20110304081550.GA30398@afflict.kos.to>
References: <20110303153737.GA23633@afflict.kos.to>
	<20110303154626.GA23686@codesourcery.com>
	<20110303161549.GA27102@afflict.kos.to>
	<20110303164639.GB23686@codesourcery.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20110303164639.GB23686@codesourcery.com>
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: Nathan Froyd <froydnj@codesourcery.com>
Cc: qemu-devel@nongnu.org

On Thu, Mar 03, 2011 at 08:46:40AM -0800, Nathan Froyd wrote:
> On Thu, Mar 03, 2011 at 06:15:49PM +0200, Riku Voipio wrote:
> > 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.

I believe 256K should be enough for everone now, then again we know 
what happened when someone suggested same about 640K.. In this case
however, if the limit is ever hit, increasing the limit again is easy.

Originally I did put the limit much higher, as I assume due to lazy
memory allocation from kernel it doesn't matter if we ask for 256K or
8M, as unused pages will never be allocated. But I'll do some testing with
lots of threads and see if stack size has an impact on how many threads
we can run.

Riku