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
"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.
W
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 point
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: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.
"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.
W
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
"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 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
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 memory is not dirty.
Signed-off-by: OHMURA Kei
---
bswap.h|2 ++
qemu-kvm.c | 31 ---
On 02/12/2010 04:03 AM, OHMURA Kei wrote:
> On 02/11/2010 Anthony Liguori wrote:
>
>> Oh, I see what's happening here. Yes, I think a leul_to_cpu() makes more
>> sense.
>>
> Maybe I'm missing something here.
> I couldn't find leul_to_cpu(), so have defined it in bswap.h.
> Correct?
>
> ---
On 02/11/2010 Anthony Liguori wrote:
> Oh, I see what's happening here. Yes, I think a leul_to_cpu() makes more
> sense.
Maybe I'm missing something here.
I couldn't find leul_to_cpu(), so have defined it in bswap.h.
Correct?
--- a/bswap.h
+++ b/bswap.h
@@ -205,8 +205,10 @@ static inline void cp
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 supp
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
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 usersp
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 su
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 a
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
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
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 especial
On 02/10/2010 05:54 PM, 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 b
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 memory is not dirty.
>>
>>
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 memory is not dirty.
>>
>>
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 02/10/2010 02:52 AM, OHMURA Kei wrote:
> for (i = 0; i < len; i++) {
> -c = bitmap[i];
> -while (c > 0) {
> -j = ffsl(c) - 1;
> -c &= ~(1u << j);
> -page_number = i * 8 + j;
> -ad
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 memory is not dirty.
>
> --- a/bswap.h
> +++ b/bswap.h
> @@ -209,7 +209,6 @@ st
25 matches
Mail list logo
