From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from eggs.gnu.org ([2001:4830:134:3::10]:58752)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <aurelien@aurel32.net>) id 1ZhKaz-0005Jd-FI
	for qemu-devel@nongnu.org; Wed, 30 Sep 2015 12:51:11 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <aurelien@aurel32.net>) id 1ZhKaX-00011J-06
	for qemu-devel@nongnu.org; Wed, 30 Sep 2015 12:51:09 -0400
Received: from hall.aurel32.net ([2001:bc8:30d7:100::1]:58603)
	by eggs.gnu.org with esmtp (Exim 4.71)
	(envelope-from <aurelien@aurel32.net>) id 1ZhKaW-0000y9-MG
	for qemu-devel@nongnu.org; Wed, 30 Sep 2015 12:50:40 -0400
Date: Wed, 30 Sep 2015 18:50:31 +0200
From: Aurelien Jarno <aurelien@aurel32.net>
Message-ID: <20150930165031.GD17449@aurel32.net>
References: <1443589786-26929-1-git-send-email-rth@twiddle.net>
	<1443589786-26929-26-git-send-email-rth@twiddle.net>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <1443589786-26929-26-git-send-email-rth@twiddle.net>
Subject: Re: [Qemu-devel] [PATCH v4 25/26] tcg: Check for overflow via
	highwater mark
List-Id: <qemu-devel.nongnu.org>
List-Unsubscribe: <https://lists.nongnu.org/mailman/options/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: <https://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: Richard Henderson <rth@twiddle.net>
Cc: peter.maydell@linaro.org, qemu-devel@nongnu.org

On 2015-09-30 15:09, Richard Henderson wrote:
> We currently pre-compute an worst case code size for any TB, which
> works out to be 122kB.  Since the average TB size is near 1kB, this
> wastes quite a lot of storage.

The code generation buffer is currently computed as 1/4 of the guest
RAM in softmmu mode (so 32MB for the default 128MB of RAM) or 32MB in
user mode. 122kB is therefore less than 0.4% of waster memory, I am not
therefore sure we need to add so much code just for that.

BTW, I wonder if it is really a good idea to scale the code generation
buffer with the size of the RAM, as the two do not seem that related. It
happens that at some point we don't really increases performances
anymore, and always defining it as 32MB might actually be a good idea.
Personally I am using a patch that limits it to 128MB.

-- 
Aurelien Jarno                          GPG: 4096R/1DDD8C9B
aurelien@aurel32.net                 http://www.aurel32.net