On 18.02.2010, at 06:57, OHMURA Kei wrote:
We think? I mean - yes, I think so too. But have you actually measured
it?
How much improvement are we talking here?
Is it still faster when a bswap is involved?
Thanks for pointing out.
I will post the data for x86 later.
However, I don't have
We think? I mean - yes, I think so too. But have you actually measured it?
How much improvement are we talking here?
Is it still faster when a bswap is involved?
Thanks for pointing out.
I will post the data for x86 later.
However, I don't have a test environment to check the impact of bswap.
On 17.02.2010, at 10:42, OHMURA Kei wrote:
We think? I mean - yes, I think so too. But have you actually measured
it?
How much improvement are we talking here?
Is it still faster when a bswap is involved?
Thanks for pointing out.
I will post the data for x86 later.
However, I don't have
On 02/17/2010 11:42 AM, OHMURA Kei wrote:
We think? I mean - yes, I think so too. But have you actually
measured it?
How much improvement are we talking here?
Is it still faster when a bswap is involved?
Thanks for pointing out.
I will post the data for x86 later.
However, I don't have a test
On 17.02.2010, at 10:47, Avi Kivity wrote:
On 02/17/2010 11:42 AM, OHMURA Kei wrote:
We think? I mean - yes, I think so too. But have you actually measured
it?
How much improvement are we talking here?
Is it still faster when a bswap is involved?
Thanks for pointing out.
I will post the
We think? I mean - yes, I think so too. But have you actually measured it?
How much improvement are we talking here?
Is it still faster when a bswap is involved?
Thanks for pointing out.
I will post the data for x86 later.
However, I don't have a test environment to check the impact of bswap.
We think? I mean - yes, I think so too. But have you actually measured it?
How much improvement are we talking here?
Is it still faster when a bswap is involved?
Thanks for pointing out.
I will post the data for x86 later.
However, I don't have a test environment to check the impact of bswap.
On 16.02.2010, at 12:16, OHMURA Kei wrote:
We think? I mean - yes, I think so too. But have you actually measured it?
How much improvement are we talking here?
Is it still faster when a bswap is involved?
Thanks for pointing out.
I will post the data for x86 later.
However, I don't have
On 15.02.2010, at 07:12, OHMURA Kei wrote:
dirty-bitmap-traveling is carried out by byte size in qemu-kvm.c.
But We think that dirty-bitmap-traveling by long size is faster than by byte
We think? I mean - yes, I think so too. But have you actually measured it?
How much improvement are we
Anthony Liguori wrote:
On 02/10/2010 07:20 AM, Avi Kivity wrote:
On 02/10/2010 12:52 PM, OHMURA Kei wrote:
dirty-bitmap-traveling is carried out by byte size in qemu-kvm.c.
But We think that dirty-bitmap-traveling by long size is faster than by byte
size especially when most of
On 02/10/2010 10:00 AM, Alexander Graf wrote:
On PPC the bitmap is Little Endian.
Out of curiousity, why? It seems like an odd interface.
Regards,
Anthony Liguori
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More
Anthony Liguori wrote:
On 02/10/2010 10:00 AM, Alexander Graf wrote:
On PPC the bitmap is Little Endian.
Out of curiousity, why? It seems like an odd interface.
Because on PPC, you usually run PPC32 userspace code on a PPC64 kernel.
Unlike with x86, there's no real benefit
On 02/10/2010 06:35 PM, Anthony Liguori wrote:
On 02/10/2010 10:00 AM, Alexander Graf wrote:
On PPC the bitmap is Little Endian.
Out of curiousity, why? It seems like an odd interface.
Exactly this issue. If you specify it as unsigned long native endian,
there is ambiguity
On 02/10/2010 06:43 PM, Alexander Graf wrote:
Out of curiousity, why? It seems like an odd interface.
Because on PPC, you usually run PPC32 userspace code on a PPC64 kernel.
Unlike with x86, there's no real benefit in using 64 bit userspace.
btw, does 32-bit ppc qemu support
Avi Kivity wrote:
On 02/10/2010 06:43 PM, Alexander Graf wrote:
Out of curiousity, why? It seems like an odd interface.
Because on PPC, you usually run PPC32 userspace code on a PPC64 kernel.
Unlike with x86, there's no real benefit in using 64 bit userspace.
On 02/10/2010 06:47 PM, Alexander Graf wrote:
Because on PPC, you usually run PPC32 userspace code on a PPC64 kernel.
Unlike with x86, there's no real benefit in using 64 bit userspace.
btw, does 32-bit ppc qemu support large memory guests? It doesn't on
x86, and I don't
Avi Kivity wrote:
On 02/10/2010 06:47 PM, Alexander Graf wrote:
Because on PPC, you usually run PPC32 userspace code on a PPC64 kernel.
Unlike with x86, there's no real benefit in using 64 bit userspace.
btw, does 32-bit ppc qemu support large memory guests? It
17 matches
Mail list logo
