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
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
On 19/07/2015 00:20, Benjamin Herrenschmidt wrote:
+ * For BookE, we need in theory 8 MMU modes, which would
+ * reduce performance, so instead, we ignore msr_hv and
+ * will flush on HV context switches. We *could* improve
+ * things a bit if needed by using 4 and 5 as HV
On Sun, 2015-07-19 at 13:56 +0200, Paolo Bonzini wrote:
On 19/07/2015 00:20, Benjamin Herrenschmidt wrote:
+ * For BookE, we need in theory 8 MMU modes, which would
+ * reduce performance, so instead, we ignore msr_hv and
+ * will flush on HV context switches. We *could*
On 19/07/2015 14:11, Benjamin Herrenschmidt wrote:
Ok, I assumed incorrectly that 8 was too much based on your changeset
comment:
At 8k per TLB (for 64-bit host or target), 8 or more modes
make the TLBs bigger than 64k, and some RISC TCG backends do
not like that. On the
On 2015-07-19 13:56, Paolo Bonzini wrote:
On 19/07/2015 00:20, Benjamin Herrenschmidt wrote:
+ * For BookE, we need in theory 8 MMU modes, which would
+ * reduce performance, so instead, we ignore msr_hv and
+ * will flush on HV context switches. We *could* improve
+ *
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
On Sun, 2015-07-19 at 19:42 +0200, Paolo Bonzini wrote:
On 19/07/2015 14:11, Benjamin Herrenschmidt wrote:
Ok, I assumed incorrectly that 8 was too much based on your changeset
comment:
At 8k per TLB (for 64-bit host or target), 8 or more modes
make the TLBs bigger than 64k,
We rework the way the MMU indices are calculated, providing separate
indices for I and D side based on MSR:IR and MSR:DR respectively,
and thus no longer need to flush the TLB on context changes. This also
adds correct support for HV as a separate address space.
Signed-off-by: Benjamin
