From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from eggs.gnu.org ([2001:4830:134:3::10]:39302)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <benh@kernel.crashing.org>) id 1ZH6Bo-0006O2-N0
	for qemu-devel@nongnu.org; Mon, 20 Jul 2015 04:12:45 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <benh@kernel.crashing.org>) id 1ZH6Bn-0003IF-M5
	for qemu-devel@nongnu.org; Mon, 20 Jul 2015 04:12:44 -0400
Message-ID: <1437379942.3775.5.camel@kernel.crashing.org>
From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Date: Mon, 20 Jul 2015 18:12:22 +1000
In-Reply-To: <20150720071106.GF472@aurel32.net>
References: <1437258018-13982-1-git-send-email-benh@kernel.crashing.org>
	<1437258018-13982-3-git-send-email-benh@kernel.crashing.org>
	<55AB9068.8050202@redhat.com> <20150719230128.GL11361@aurel32.net>
	<1437348796.28088.122.camel@kernel.crashing.org>
	<20150720071106.GF472@aurel32.net>
Content-Type: text/plain; charset="UTF-8"
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
Subject: Re: [Qemu-devel] [RFC PATCH 3/4] ppc: Use split I/D mmu modes to
 avoid flushes on interrupts
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: Aurelien Jarno <aurelien@aurel32.net>
Cc: Paolo Bonzini <pbonzini@redhat.com>, qemu-ppc@nongnu.org, qemu-devel@nongnu.org

On Mon, 2015-07-20 at 09:11 +0200, Aurelien Jarno wrote:
> 
> Understood. I did some tests showing that the number of instructions
> in
> the fast path doesn't not have a big performance impact. In that case,
> there is dependency between instructions, but anyway the CPU is likely
> to be stalled by the TLB entry to the memory access, so we can add one
> instruction before with very little impact.

Possibly, though I would expect the TLB to be pretty hot in the cache.
The likelihood of successive accesses being close to each other (or even
in the same page) is also quite high. It might be something worth
instrumenting some day.

The one thing that might prove a gain for some workloads would be to add
TCG primitives for simple vector load/stores... with gcc being more and
more aggressive these days at using them for moving things around (and
glibc memcpy), it might be a measurable gain.
 
> I'll keep this idea in my todo list for another day.

My todo list tend to be a O_WRONLY file sadly :-)

Cheers,
Ben.