qemu-kvm: Speed up of the dirty-bitmap-traveling
PATCH v2 1/1 qemu-kvm: Speed up of the dirty-bitmap-traveling
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.
--- bswap.h | 1 - qemu-kvm.c | 30 ++++++++++++++++-------------- 2 files changed, 16 insertions(+), 15 deletions(-)
bswap.h +0 -1
@@ -209,7 +209,6 @@ static inline void cpu_to_be32wu(uint32_t *p, uint32_t v)#define cpu_to_32wu cpu_to_le32wu#endif -#undef le_bswap#undef be_bswap#undef le_bswaps#undef be_bswaps
qemu-kvm.c +16 -14
@@ -2438,27 +2438,29 @@ static int kvm_get_dirty_pages_log_range(unsigned long start_addr, unsigned long offset, unsigned long mem_size) { -unsigned int i, j, n =0 ; -unsigned char c; -unsigned long page_number, addr, addr1; +unsigned int i, j; +unsigned long page_number, addr, addr1, c;ram_addr_t ram_addr; -unsigned int len = ((mem_size /TARGET_PAGE_SIZE ) +7 ) /8 ; +unsigned int len = ((mem_size /TARGET_PAGE_SIZE ) +HOST_LONG_BITS -1 ) / +HOST_LONG_BITS ; +unsigned long *bitmap_ul = (unsigned long *)bitmap;/* * bitmap-traveling is faster than memory-traveling (for addr...) * especially when most of the memory is not dirty. */ for (i =0 ; i < len; i++) { - c = bitmap[i]; -while (c >0 ) { - j =ffsl (c) -1 ; - c &= ~(1u << j); - page_number = i *8 + j; - addr1 = page_number *TARGET_PAGE_SIZE ; - addr = offset + addr1; - ram_addr =cpu_get_physical_page_desc (addr); -cpu_physical_memory_set_dirty (ram_addr); - n++; +if (bitmap_ul[i] !=0 ) { + c =le_bswap (bitmap_ul[i],HOST_LONG_BITS ); +while (c >0 ) { + j =ffsl (c) -1 ; + c &= ~(1ul << j); + page_number = i *HOST_LONG_BITS + j; + addr1 = page_number *TARGET_PAGE_SIZE ; + addr = offset + addr1; + ram_addr =cpu_get_physical_page_desc (addr); +cpu_physical_memory_set_dirty (ram_addr); + } } }return 0 ;
Signature · 1 line
1.6.3.3
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Quoted 12 lines · OHMURA Kei
for (i = 0; i < len; i++) {qemu-kvm.c +1
-10- c = bitmap[i]; -while (c >0 ) { - j =ffsl (c) -1 ; - c &= ~(1u << j); - page_number = i *8 + j; - addr1 = page_number *TARGET_PAGE_SIZE ; - addr = offset + addr1; - ram_addr =cpu_get_physical_page_desc (addr); -cpu_physical_memory_set_dirty (ram_addr); - n++; +if (bitmap_ul[i] !=0 ) {
qemu-kvm.c static int kvm_get_dirty_pages_log_range(unsigned long start_addr, · line 2463
Quoted 10 lines
qemu-kvm.c +10
-0+ c =le_bswap (bitmap_ul[i],HOST_LONG_BITS ); +while (c >0 ) { + j =ffsl (c) -1 ; + c &= ~(1ul << j); + page_number = i *HOST_LONG_BITS + j; + addr1 = page_number *TARGET_PAGE_SIZE ; + addr = offset + addr1; + ram_addr =cpu_get_physical_page_desc (addr); +cpu_physical_memory_set_dirty (ram_addr); + }
If you're optimizing this code you might want to do it all. The compiler might not see through the bswap call and create unnecessary data dependencies. Especially problematic if the bitmap is really sparse. Also, the outer test is != while the inner test is >. Be consistent. I suggest to replace the inner loop with
do {
...
} while (c != 0);Depending on how sparse the bitmap is populated this might reduce the number of data dependencies quite a bit.
- --
➧ Ulrich Drepper ➧ Red Hat, Inc. ➧ 444 Castro St ➧ Mountain View, CA ❖ -----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
iEYEARECAAYFAktysDoACgkQ2ijCOnn/RHS2zwCfcj+G0S5ZAEA8MjGAVI/rKjJJ +0oAnA4njIrwx3/5+o43ekYeYXSNyei0
=ukkz
-----END PGP SIGNATURE-----
Quoted 7 lines · OHMURA Kei
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.
bswap.h static inline void cpu_to_be32wu(uint32_t *p, uint32_t v) · line 214
Quoted 7 lines
bswap.h +0
-1@@ -209,7 +209,6 @@ static inline void cpu_to_be32wu(uint32_t *p, uint32_t v)#define cpu_to_32wu cpu_to_le32wu#endif -#undef le_bswap#undef be_bswap#undef le_bswaps
Anthony, is it okay to export le_bswap this way, or will you want leul_to_cpu()?
Signature · 1 line
error compiling committee.c: too many arguments to function
Quoted 12 lines · Avi Kivity
Quoted 10 lines · OHMURA Kei
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.bswap.h +0
-0@@ -209,7 +209,6 @@ static inline void cpu_to_be32wu(uint32_t *p, uint32_t v)#define cpu_to_32wu cpu_to_le32wu#endif
Quoted 9 lines
bswap.h static inline void cpu_to_be32wu(uint32_t *p, uint32_t v)
Quoted 5 lines
bswap.h +0
-1-#undef le_bswap#undef be_bswap#undef le_bswapsAnthony, is it okay to export
le_bswapthis way, or will you wantleul_to_cpu()?
kvm_get_dirty_pages_log_range() is kvm-specific code. We're guaranteed that when we're using kvm, target byte order == host byte order.
So is it really necessary to use a byte swapping function at all?
Regards,
Anthony Liguori
Quoted 25 lines · Anthony Liguori
Quoted 13 lines · Avi Kivity
Quoted 10 lines · OHMURA Kei
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.bswap.h +0
-0@@ -209,7 +209,6 @@ static inline void cpu_to_be32wu(uint32_t *p, uint32_t v)#define cpu_to_32wu cpu_to_le32wu#endif Quoted 10 lines
bswap.h static inline void cpu_to_be32wu(uint32_t *p, uint32_t v)
Quoted 6 lines
bswap.h +0
-1-#undef le_bswap#undef be_bswap#undef le_bswapsAnthony, is it okay to export
le_bswapthis way, or will you wantleul_to_cpu()?
Quoted 5 lines
kvm_get_dirty_pages_log_range()is kvm-specific code. We're guaranteed that when we're using kvm, target byte order == host byte order.So is it really necessary to use a byte swapping function at all?
The dirty log bitmap is always little endian. This is so we don't have to depend on sizeof(long) (which can vary between kernel and userspace) or mandate some other access size.
(if native endian worked, then the previous byte-based code would have been broken on big endian).
Seriously, those who say that big vs little endian is a matter of taste are missing something.
Signature · 1 line
error compiling committee.c: too many arguments to function
Quoted 26 lines · Anthony Liguori
Quoted 13 lines · Avi Kivity
Quoted 10 lines · OHMURA Kei
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.bswap.h +0
-0@@ -209,7 +209,6 @@ static inline void cpu_to_be32wu(uint32_t *p, uint32_t v)#define cpu_to_32wu cpu_to_le32wu#endif Quoted 10 lines
bswap.h static inline void cpu_to_be32wu(uint32_t *p, uint32_t v)
Quoted 6 lines
bswap.h +0
-1-#undef le_bswap#undef be_bswap#undef le_bswapsAnthony, is it okay to export
le_bswapthis way, or will you wantleul_to_cpu()?
Quoted 5 lines
kvm_get_dirty_pages_log_range()is kvm-specific code. We're guaranteed that when we're using kvm, target byte order == host byte order.So is it really necessary to use a byte swapping function at all?
On PPC the bitmap is Little Endian.
Alex
Quoted 2 lines · Alexander Graf
On PPC the bitmap is Little Endian.
Out of curiousity, why? It seems like an odd interface.
Regards,
Anthony Liguori
Quoted 8 lines · Anthony Liguori
Quoted 3 lines · Alexander Graf
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 in using 64 bit userspace.
So thanks to the nature of big endianness, that breaks our set_bit helpers, because they assume you're using "long" data types for the bits. While that's no real issue on little endian, since the next int is just the high part of a u64, it messes everything up on ppc.
For more details, please just look in the archives on my patches to make it little endian.
Alex
Quoted 7 lines · Alexander Graf
Quoted 4 lines
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 large memory guests? It doesn't on x86, and I don't remember any hacks to support large memory guests elsewhere.
Signature · 1 line
error compiling committee.c: too many arguments to function
Quoted 6 lines · Avi Kivity
Quoted 4 lines · Alexander Graf
Quoted 4 lines
Out of curiousity, why? It seems like an odd interface.
Quoted 9 lines
Quoted 4 lines
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 remember any hacks to support large memory guests elsewhere.
It doesn't :-). In fact, the guest we virtualize wouldn't work with > 2 GB anyways, because that needs an iommu implementation.
Alex
Quoted 5 lines · Alexander Graf
Quoted 5 lines
Quoted 5 lines
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.
Quoted 9 lines
Quoted 5 lines
btw, does 32-bit ppc qemu support large memory guests? It doesn't on x86, and I don't remember any hacks to support large memory guests elsewhere.
It doesn't :-). In fact, the guest we virtualize wouldn't work with > 2 GB anyways, because that needs an iommu implementation.
Oh, so you may want to revisit the "there's no real benefit in using 64 bit userspace".
Seriously, that looks like a big deficiency. What would it take to implement an iommu?
I imagine Anthony's latest patches are a first step in that journey.
Signature · 1 line
error compiling committee.c: too many arguments to function
Quoted 14 lines · Avi Kivity
Quoted 12 lines · Alexander Graf
Quoted 12 lines
Quoted 6 lines
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 remember any hacks to support large memory guests elsewhere.
Quoted 8 lines
Quoted 4 lines
It doesn't :-). In fact, the guest we virtualize wouldn't work with > 2 GB anyways, because that needs an iommu implementation.
Oh, so you may want to revisit the "there's no real benefit in using 64 bit userspace".
Well, for normal users they don't. SLES11 is 64-bit only, so we're good on that. But openSUSE uses 32-bit userland.
Quoted 5 lines
Seriously, that looks like a big deficiency. What would it take to implement an iommu?
I imagine Anthony's latest patches are a first step in that journey.
All reads/writes from PCI devices would need to go through a wrapper. Maybe we could also define a per-device offset for memory accesses. That way the overhead might be less.
Yes, Anthony's patches look like they are a really big step in that direction.
Alex
Quoted 8 lines · Anthony Liguori
Quoted 3 lines · Alexander Graf
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 between 32-bit and 64-bit userspace. If you specify it as uint64_t native endian, you have an inefficient implementation on 32-bit userspace. So we went for unsigned byte native endian, which is the same as any size little endian.
(well I think the real reason is that it just grew that way out of x86, but the above is quite plausible).
Signature · 1 line
error compiling committee.c: too many arguments to function
Quoted 12 lines · Avi Kivity
Quoted 10 lines · OHMURA Kei
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.bswap.h +0
-0@@ -209,7 +209,6 @@ static inline void cpu_to_be32wu(uint32_t *p, uint32_t v)#define cpu_to_32wu cpu_to_le32wu#endif
Quoted 9 lines
bswap.h static inline void cpu_to_be32wu(uint32_t *p, uint32_t v)
Quoted 5 lines
bswap.h +0
-1-#undef le_bswap#undef be_bswap#undef le_bswapsAnthony, is it okay to export
le_bswapthis way, or will you wantleul_to_cpu()?
Oh, I see what's happening here. Yes, I think a leul_to_cpu() makes more sense.
Regards,
Anthony Liguori
Quoted 2 lines · On 02/11/2010 Anthony Liguori <[email protected]> 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?
bswap.h +2 -0
@@ -205,8 +205,10 @@ static inline void cpu_to_be32wu(uint32_t *p, uint32_t v)#ifdef HOST_WORDS_BIGENDIAN #define cpu_to_32wu cpu_to_be32wu +#define leul_to_cpu (v) le ## HOST_LONG_BITS ## _to_cpu(v)#else #define cpu_to_32wu cpu_to_le32wu +#define leul_to_cpu (v) (v)#endif
Quoted 6 lines · On 02/10/2010 Ulrich Drepper <[email protected]> wrote:
If you're optimizing this code you might want to do it all. The compiler might not see through the bswap call and create unnecessary data dependencies. Especially problematic if the bitmap is really sparse. Also, the outer test is != while the inner test is >. Be consistent. I suggest to replace the inner loop with
Quoted 6 lines
do { ... } while (c != 0);Depending on how sparse the bitmap is populated this might reduce the number of data dependencies quite a bit.
Combining all comments, the code would be like this.
if (bitmap_ul[i] != 0) {
c = leul_to_cpu(bitmap_ul[i]);
do {
j = ffsl(c) - 1;
c &= ~(1ul << j);
page_number = i * HOST_LONG_BITS + j;
addr1 = page_number * TARGET_PAGE_SIZE;
addr = offset + addr1;
ram_addr = cpu_get_physical_page_desc(addr);
cpu_physical_memory_set_dirty(ram_addr);
} while (c != 0);}
Quoted 51 lines · OHMURA Kei
Quoted 3 lines · On 02/11/2010 Anthony Liguori <[email protected]> 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 findleul_to_cpu(), so have defined it inbswap.h. Correct?bswap.h +2
-0@@ -205,8 +205,10 @@ static inline void cpu_to_be32wu(uint32_t *p, uint32_t v)#ifdef HOST_WORDS_BIGENDIAN #define cpu_to_32wu cpu_to_be32wu +#define leul_to_cpu (v) le ## HOST_LONG_BITS ## _to_cpu(v)#else #define cpu_to_32wu cpu_to_le32wu +#define leul_to_cpu (v) (v)#endif Quoted 6 lines · On 02/10/2010 Ulrich Drepper <[email protected]> wrote:
If you're optimizing this code you might want to do it all. The compiler might not see through the bswap call and create unnecessary data dependencies. Especially problematic if the bitmap is really sparse. Also, the outer test is != while the inner test is >. Be consistent. I suggest to replace the inner loop with
Quoted 7 lines
do { ... } while (c != 0);Depending on how sparse the bitmap is populated this might reduce the number of data dependencies quite a bit.
Combining all comments, the code would be like this.
if (bitmap_ul[i] != 0) { c = leul_to_cpu(bitmap_ul[i]); do { j = ffsl(c) - 1; c &= ~(1ul << j); page_number = i * HOST_LONG_BITS + j; addr1 = page_number * TARGET_PAGE_SIZE; addr = offset + addr1; ram_addr = cpu_get_physical_page_desc(addr); cpu_physical_memory_set_dirty(ram_addr); } while (c != 0);
Quoted 2 lines
}
Except you don't need bitmap_ul any more - you can change the type of the bitmap variable, since all accesses should now be ulongs.
Signature · 1 line
error compiling committee.c: too many arguments to function
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.
--- bswap.h | 2 ++ qemu-kvm.c | 31 ++++++++++++++++--------------- 2 files changed, 18 insertions(+), 15 deletions(-)
bswap.h +2 -0
@@ -205,8 +205,10 @@ static inline void cpu_to_be32wu(uint32_t *p, uint32_t v)#ifdef HOST_WORDS_BIGENDIAN #define cpu_to_32wu cpu_to_be32wu +#define leul_to_cpu (v) le ## HOST_LONG_BITS ## _to_cpu(v)#else #define cpu_to_32wu cpu_to_le32wu +#define leul_to_cpu (v) (v)#endif #undef le_bswap
qemu-kvm.c +16 -15
@@ -2434,31 +2434,32 @@ int kvm_physical_memory_set_dirty_tracking(int enable)/* get kvm's dirty pages bitmap and update qemu's */ static int kvm_get_dirty_pages_log_range (unsigned long start_addr, -unsigned char *bitmap, +unsigned long *bitmap,unsigned long offset,unsigned long mem_size) { -unsigned int i, j, n =0 ; -unsigned char c; -unsigned long page_number, addr, addr1; +unsigned int i, j; +unsigned long page_number, addr, addr1, c;ram_addr_t ram_addr; -unsigned int len = ((mem_size /TARGET_PAGE_SIZE ) +7 ) /8 ; +unsigned int len = ((mem_size /TARGET_PAGE_SIZE ) +HOST_LONG_BITS -1 ) / +HOST_LONG_BITS ;/* * bitmap-traveling is faster than memory-traveling (for addr...) * especially when most of the memory is not dirty. */ for (i =0 ; i < len; i++) { - c = bitmap[i]; -while (c >0 ) { - j =ffsl (c) -1 ; - c &= ~(1u << j); - page_number = i *8 + j; - addr1 = page_number *TARGET_PAGE_SIZE ; - addr = offset + addr1; - ram_addr =cpu_get_physical_page_desc (addr); -cpu_physical_memory_set_dirty (ram_addr); - n++; +if (bitmap[i] !=0 ) { + c =leul_to_cpu (bitmap[i]); +do { + j =ffsl (c) -1 ; + c &= ~(1ul << j); + page_number = i *HOST_LONG_BITS + j; + addr1 = page_number *TARGET_PAGE_SIZE ; + addr = offset + addr1; + ram_addr =cpu_get_physical_page_desc (addr); +cpu_physical_memory_set_dirty (ram_addr); + }while (c !=0 ); } }return 0 ;
Signature · 1 line
1.6.3.3
Quoted 2 lines · OHMURA Kei
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 talking here? Is it still faster when a bswap is involved?
Alex
Quoted 3 lines
"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. Would you please measure the run time between the following section if possible?
start ->qemu-kvm.c:
static int kvm_get_dirty_bitmap_cb(unsigned long start, unsigned long len,
void *bitmap, void *opaque)
{
/* warm up each function */ kvm_get_dirty_pages_log_range(start, bitmap, start, len); kvm_get_dirty_pages_log_range_new(start, bitmap, start, len);
/* measurement */
int64_t t1, t2;
t1 = cpu_get_real_ticks();
kvm_get_dirty_pages_log_range(start, bitmap, start, len);
t1 = cpu_get_real_ticks() - t1;
t2 = cpu_get_real_ticks();
kvm_get_dirty_pages_log_range_new(start, bitmap, start, len);
t2 = cpu_get_real_ticks() - t2;
printf("## %zd, %zd\n", t1, t2); fflush(stdout); return kvm_get_dirty_pages_log_range_new(start, bitmap, start, len);
}
end ->
Quoted 8 lines · OHMURA Kei
Quoted 3 lines
"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. Would you please measure the run time between the following section if possible?
It'd make more sense to have a real stand alone test program, no?
I can try to write one today, but I have some really nasty important bugs to fix first.
Alex
Quoted 10 lines
Quoted 7 lines
Quoted 3 lines
"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. Would you please measure the run time between the following section if possible?It'd make more sense to have a real stand alone test program, no?
I can try to write one today, but I have some really nasty important bugs to fix first.
OK. I will prepare a test code with sample data. Since I found a ppc machine around, I will run the code and post the results of x86 and ppc.
By the way, the following data is a result of x86 measured in QEMU/KVM.
This data shows, how many times the function is called (#called), runtime of original function(orig.), runtime of this patch(patch), speedup ratio (ratio).
Test1: Guest OS read 3GB file, which is bigger than memory.
#called orig.(msec) patch(msec) ratio 108 1.1 0.1 7.6 102 1.0 0.1 6.8 132 1.6 0.2 7.1
Test2: Guest OS read/write 3GB file, which is bigger than memory.
#called orig.(msec) patch(msec) ratio 2394 33 7.7 4.3 2100 29 7.1 4.1 2832 40 9.9 4.0
Quoted 11 lines · OHMURA Kei
Quoted 9 lines
Quoted 7 lines
Quoted 3 lines
"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. Would you please measure the run time between the following section if possible?It'd make more sense to have a real stand alone test program, no?
I can try to write one today, but I have some really nasty important bugs to fix first.
Quoted 6 lines
OK. I will prepare a test code with sample data. Since I found a ppc machine around, I will run the code and post the results of x86 and ppc.
By the way, the following data is a result of x86 measured in QEMU/KVM.
This data shows, how many times the function is called (#called), runtime of original function(orig.), runtime of this patch(patch), speedup ratio (ratio).
That does indeed look promising!
Thanks for doing this micro-benchmark. I just want to be 100% sure that it doesn't affect performance for big endian badly.
Alex
Quoted 14 lines
Quoted 14 lines
Quoted 9 lines
Quoted 7 lines
Quoted 3 lines
"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. Would you please measure the run time between the following section if possible?It'd make more sense to have a real stand alone test program, no?
I can try to write one today, but I have some really nasty important bugs to fix first.OK. I will prepare a test code with sample data. Since I found a ppc machine around, I will run the code and post the results of x86 and ppc.
Quoted 5 lines
Quoted 1 line
By the way, the following data is a result of x86 measured in QEMU/KVM. This data shows, how many times the function is called (#called), runtime of original function(orig.), runtime of this patch(patch), speedup ratio (ratio).
That does indeed look promising!
Thanks for doing this micro-benchmark. I just want to be 100% sure that it doesn't affect performance for big endian badly.
I measured runtime of the test code with sample data. My test environment and results are described below.
x86 Test Environment:
CPU: 4x Intel Xeon Quad Core 2.66GHz
Mem size: 6GB
ppc Test Environment:
CPU: 2x Dual Core PPC970MP
Mem size: 2GB
The sample data of dirty bitmap was produced by QEMU/KVM while the guest OS was live migrating. To measure the runtime I copied cpu_get_real_ticks() of QEMU to my test program.
Experimental results:
Test1: Guest OS read 3GB file, which is bigger than memory.
orig.(msec) patch(msec) ratio
x86 0.3 0.1 6.4 ppc 7.9 2.7 3.0
Test2: Guest OS read/write 3GB file, which is bigger than memory.
orig.(msec) patch(msec) ratio
x86 12.0 3.2 3.7 ppc 251.1 123 2.0
I also measured the runtime of bswap itself on ppc, and I found it was only just 0.3% ~ 0.7 % of the runtime described above.
Quoted 34 lines · OHMURA Kei
Quoted 10 lines
Quoted 10 lines
Quoted 9 lines
Quoted 7 lines
Quoted 3 lines
"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. Would you please measure the run time between the following section if possible?It'd make more sense to have a real stand alone test program, no?
I can try to write one today, but I have some really nasty important bugs to fix first.Quoted 7 lines
Quoted 5 lines
OK. I will prepare a test code with sample data. Since I found a ppc machine around, I will run the code and post the results of x86 and ppc.
By the way, the following data is a result of x86 measured in QEMU/KVM. This data shows, how many times the function is called (#called), runtime of original function(orig.), runtime of this patch(patch), speedup ratio (ratio).
That does indeed look promising!
Thanks for doing this micro-benchmark. I just want to be 100% sure that it doesn't affect performance for big endian badly.I measured runtime of the test code with sample data. My test environment and results are described below.
x86 Test Environment:
CPU: 4x Intel Xeon Quad Core 2.66GHzMem size: 6GB
ppc Test Environment:
CPU: 2x Dual Core PPC970MPMem size: 2GB
The sample data of dirty bitmap was produced by QEMU/KVM while the guest OS was live migrating. To measure the runtime I copied
cpu_get_real_ticks()of QEMU to my test program.
Quoted 7 lines
Experimental results:
Test1: Guest OS read 3GB file, which is bigger than memory. orig.(msec) patch(msec) ratio
x86 0.3 0.1 6.4 ppc 7.9 2.7 3.0
Test2: Guest OS read/write 3GB file, which is bigger than memory. orig.(msec) patch(msec) ratio
x86 12.0 3.2 3.7 ppc 251.1 123 2.0I also measured the runtime of bswap itself on ppc, and I found it was only just 0.3% ~ 0.7 % of the runtime described above.
Awesome! Thank you so much for giving actual data to make me feel comfortable with it :-).
Alex
Quoted 8 lines · OHMURA Kei
Quoted 8 lines
Quoted 7 lines
Quoted 3 lines
"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. Would you please measure the run time between the following section if possible?
Quoted 7 lines
Quoted 2 lines
It'd make more sense to have a real stand alone test program, no?
I can try to write one today, but I have some really nasty important bugs to fix first.OK. I will prepare a test code with sample data. Since I found a ppc machine around, I will run the code and post the results of x86 and ppc.
I've applied the patch - I think the x86 results justify it, and I'll be very surprised if ppc doesn't show a similar gain. Skipping 7 memory accesses and 7 tests must be a win.
Signature · 1 line
error compiling committee.c: too many arguments to function
Quoted 13 lines · Avi Kivity
Quoted 12 lines · OHMURA Kei
Quoted 10 lines
Quoted 7 lines
Quoted 3 lines
"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. Would you please measure the run time between the following section if possible?It'd make more sense to have a real stand alone test program, no?
I can try to write one today, but I have some really nasty important bugs to fix first.
Quoted 5 lines
Quoted 3 lines
OK. I will prepare a test code with sample data. Since I found a ppc machine around, I will run the code and post the results of x86 and ppc.
I've applied the patch - I think the x86 results justify it, and I'll be very surprised if ppc doesn't show a similar gain. Skipping 7 memory accesses and 7 tests must be a win.
Sounds good to me. I don't assume bswap to be horribly slow either. Just want to be sure.
Alex