From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:49094) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZhNiq-0004ln-J8 for qemu-devel@nongnu.org; Wed, 30 Sep 2015 16:11:29 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZhNin-0006gM-Dz for qemu-devel@nongnu.org; Wed, 30 Sep 2015 16:11:28 -0400 Received: from mail-pa0-x233.google.com ([2607:f8b0:400e:c03::233]:34482) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZhNin-0006gE-8e for qemu-devel@nongnu.org; Wed, 30 Sep 2015 16:11:25 -0400 Received: by padhy16 with SMTP id hy16so50036601pad.1 for ; Wed, 30 Sep 2015 13:11:24 -0700 (PDT) Sender: Richard Henderson References: <1443589786-26929-1-git-send-email-rth@twiddle.net> <1443589786-26929-26-git-send-email-rth@twiddle.net> <20150930165031.GD17449@aurel32.net> From: Richard Henderson Message-ID: <560C41E5.9050808@twiddle.net> Date: Thu, 1 Oct 2015 06:11:17 +1000 MIME-Version: 1.0 In-Reply-To: <20150930165031.GD17449@aurel32.net> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH v4 25/26] tcg: Check for overflow via highwater mark List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org, peter.maydell@linaro.org On 10/01/2015 02:50 AM, Aurelien Jarno wrote: > 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. It depends on the guest and the workload I suppose. For alpha, which almost never flushes the buffer, allocating 2GB to the guest (and thus 512MB to the buffer) seems to reach a nice steady-state during a guest gcc bootstrap where no more code generation is required. If I were to limit the buffer to significantly less, as you're suggesting, I believe that the working set would overflow the buffer, requiring more code generation. I guess I could always use -tb-size myself to override... r~