From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:50549) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZUIf4-0005Qh-Lq for qemu-devel@nongnu.org; Tue, 25 Aug 2015 14:09:31 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZUIez-0008Kl-LL for qemu-devel@nongnu.org; Tue, 25 Aug 2015 14:09:30 -0400 Received: from mail-qg0-x232.google.com ([2607:f8b0:400d:c04::232]:35665) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZUIez-0008Jg-Gd for qemu-devel@nongnu.org; Tue, 25 Aug 2015 14:09:25 -0400 Received: by qgj62 with SMTP id 62so111325004qgj.2 for ; Tue, 25 Aug 2015 11:09:24 -0700 (PDT) Sender: Richard Henderson References: <1440476386-7365-1-git-send-email-rth@twiddle.net> <55DC00F7.5010100@gmx.net> <55DC7ACE.702@twiddle.net> <55DC7DC5.9010204@gmx.net> From: Richard Henderson Message-ID: <55DCAF50.30807@twiddle.net> Date: Tue, 25 Aug 2015 11:09:20 -0700 MIME-Version: 1.0 In-Reply-To: <55DC7DC5.9010204@gmx.net> Content-Type: text/plain; charset=iso-8859-15; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH] target-sparc: Store mmu index in TB flags List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Dennis Luehring , Artyom Tarasenko Cc: Mark Cave-Ayland , qemu-devel , Aurelien Jarno On 08/25/2015 07:37 AM, Dennis Luehring wrote: > Am 25.08.2015 um 16:25 schrieb Richard Henderson: >> Er, no, it should. The primary vector by which I expect improvement is via not >> encoding dmmu.mmu_primary_context into the TB flags. I.e. ASI_DMMU, which >> sun4u certainly uses. >> >> The fact that the patch_also_ fixes a sun4v problem is secondary. > > please, can you(or someone else) give me a feedback about my tests/numbers - > and the relevance of them - the stream benchmarks results seems to be worser > then before and the compilespeed is just a little bit better - so i don't understand (at > all) what problems are fixed or what is improved now The fact that stream degraded means that stream is unreliable as a benchmark. I suspect that if you simply run it N times with the exact same setup you'll see a very large variance in its runtime. This particular patch cannot possibly have degraded performance, as it could only result in a reduction, not expansion, of the number of TBs created. As to why stream should be unreliable, I have no clue. > - the compilation test is still 180 times slower then on my host I'll have to compare that test vs an Alpha guest and see what I get. I only remember one factor of 10, not two... But you're right, it would be nice to put together a coherent set of benchmarks. Ideally, a guest kernel plus minimal ramdisk with the tests pre-loaded so that we can boot and run ./benchmark at the prompt. That's the sort of thing we can easily upload to the wiki and share. r~