qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Aurelien Jarno <aurelien@aurel32.net>
To: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Paolo Bonzini <pbonzini@redhat.com>,
	qemu-ppc@nongnu.org, qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] [RFC PATCH 3/4] ppc: Use split I/D mmu modes to avoid flushes on interrupts
Date: Mon, 20 Jul 2015 09:11:06 +0200	[thread overview]
Message-ID: <20150720071106.GF472@aurel32.net> (raw)
In-Reply-To: <1437348796.28088.122.camel@kernel.crashing.org>

On 2015-07-20 09:33, Benjamin Herrenschmidt wrote:
> On Mon, 2015-07-20 at 01:01 +0200, Aurelien Jarno wrote:
> > One way to improve this would be to reduce the size of a TLB entry.
> > Currently we store the page address separately for read, write and
> > code. The information is therefore quite redundant.
> > 
> > We might want to have only one page address entry and encode if it is
> > allowed for read, write or code in the low bits just like we do for
> > invalid, mmio or dirty. This means the TLB entry can be checked with
> > 
> >   env->tlb_table[mmu_idx][page_index].ADDR == 
> >   (addr & (TARGET_PAGE_MASK | (DATA_SIZE - 1))) | READ/WRITE/CODE) 
> > 
> > with READ/WRITE/CODE each being a different bit (they can probably even
> > replace invalid). In practice it means one more instruction in the fast
> > path (one or with a 8-bit immediate), but it allows to divide the size
> > of a TLB entry by two on a 64-bit machine. It might be worth a try.
> 
> It might but that means "fixing" all tcg backends which I'm not necessarily
> looking forward to :-) The cost of that one or might be minimum on some
> processor but I wouldn't bet on it as we have basically all dependent
> instructions.

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.

I'll keep this idea in my todo list for another day.

Aurelien

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

  reply	other threads:[~2015-07-20  7:11 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-07-18 22:20 [Qemu-devel] [RFC PATCH 1/4] ppc: Remove MMU_MODEn_SUFFIX definitions Benjamin Herrenschmidt
2015-07-18 22:20 ` [Qemu-devel] [RFC PATCH 2/4] tlb: Add "ifetch" argument to cpu_mmu_index() Benjamin Herrenschmidt
2015-07-18 22:20 ` [Qemu-devel] [RFC PATCH 3/4] ppc: Use split I/D mmu modes to avoid flushes on interrupts Benjamin Herrenschmidt
2015-07-19 11:56   ` Paolo Bonzini
2015-07-19 12:11     ` Benjamin Herrenschmidt
2015-07-19 17:42       ` Paolo Bonzini
2015-07-19 21:51         ` Benjamin Herrenschmidt
2015-07-19 23:01     ` Aurelien Jarno
2015-07-19 23:33       ` Benjamin Herrenschmidt
2015-07-20  7:11         ` Aurelien Jarno [this message]
2015-07-20  8:12           ` Benjamin Herrenschmidt
2015-07-18 22:20 ` [Qemu-devel] [RFC PATCH 4/4] ppc: Do some batching of TCG tlb flushes Benjamin Herrenschmidt

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20150720071106.GF472@aurel32.net \
    --to=aurelien@aurel32.net \
    --cc=benh@kernel.crashing.org \
    --cc=pbonzini@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=qemu-ppc@nongnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).