* [Qemu-devel] [PATCH 0/3] Cleanup migration/ram.c
@ 2019-04-30 3:44 Wei Yang
2019-04-30 3:44 ` Wei Yang
` (5 more replies)
0 siblings, 6 replies; 33+ messages in thread
From: Wei Yang @ 2019-04-30 3:44 UTC (permalink / raw)
To: qemu-devel; +Cc: pbonzini, quintela, dgilbert, Wei Yang
The *start* of migration_bitmap_sync_range is always 0, we can remove this
parameter.
Since RAMBlock->offset is always *word* aligned, we can remove the check on
offset and simplify the logic a little.
Wei Yang (3):
migration/ram.c: start of migration_bitmap_sync_range is always 0
migration/ram.c: start of cpu_physical_memory_sync_dirty_bitmap is
always 0
ram: RAMBlock->offset is always aligned to a word
include/exec/ram_addr.h | 24 ++++++++++++------------
migration/ram.c | 8 ++++----
2 files changed, 16 insertions(+), 16 deletions(-)
--
2.19.1
^ permalink raw reply [flat|nested] 33+ messages in thread* [Qemu-devel] [PATCH 0/3] Cleanup migration/ram.c 2019-04-30 3:44 [Qemu-devel] [PATCH 0/3] Cleanup migration/ram.c Wei Yang @ 2019-04-30 3:44 ` Wei Yang 2019-04-30 3:44 ` [Qemu-devel] [PATCH 1/3] migration/ram.c: start of migration_bitmap_sync_range is always 0 Wei Yang ` (4 subsequent siblings) 5 siblings, 0 replies; 33+ messages in thread From: Wei Yang @ 2019-04-30 3:44 UTC (permalink / raw) To: qemu-devel; +Cc: pbonzini, Wei Yang, dgilbert, quintela The *start* of migration_bitmap_sync_range is always 0, we can remove this parameter. Since RAMBlock->offset is always *word* aligned, we can remove the check on offset and simplify the logic a little. Wei Yang (3): migration/ram.c: start of migration_bitmap_sync_range is always 0 migration/ram.c: start of cpu_physical_memory_sync_dirty_bitmap is always 0 ram: RAMBlock->offset is always aligned to a word include/exec/ram_addr.h | 24 ++++++++++++------------ migration/ram.c | 8 ++++---- 2 files changed, 16 insertions(+), 16 deletions(-) -- 2.19.1 ^ permalink raw reply [flat|nested] 33+ messages in thread
* [Qemu-devel] [PATCH 1/3] migration/ram.c: start of migration_bitmap_sync_range is always 0 2019-04-30 3:44 [Qemu-devel] [PATCH 0/3] Cleanup migration/ram.c Wei Yang 2019-04-30 3:44 ` Wei Yang @ 2019-04-30 3:44 ` Wei Yang 2019-04-30 3:44 ` Wei Yang ` (2 more replies) 2019-04-30 3:44 ` [Qemu-devel] [PATCH 2/3] migration/ram.c: start of cpu_physical_memory_sync_dirty_bitmap " Wei Yang ` (3 subsequent siblings) 5 siblings, 3 replies; 33+ messages in thread From: Wei Yang @ 2019-04-30 3:44 UTC (permalink / raw) To: qemu-devel; +Cc: pbonzini, quintela, dgilbert, Wei Yang We can eliminate to pass 0. Signed-off-by: Wei Yang <richardw.yang@linux.intel.com> --- migration/ram.c | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/migration/ram.c b/migration/ram.c index 35bd6213e9..9948b2d021 100644 --- a/migration/ram.c +++ b/migration/ram.c @@ -1643,10 +1643,10 @@ static inline bool migration_bitmap_clear_dirty(RAMState *rs, } static void migration_bitmap_sync_range(RAMState *rs, RAMBlock *rb, - ram_addr_t start, ram_addr_t length) + ram_addr_t length) { rs->migration_dirty_pages += - cpu_physical_memory_sync_dirty_bitmap(rb, start, length, + cpu_physical_memory_sync_dirty_bitmap(rb, 0, length, &rs->num_dirty_pages_period); } @@ -1735,7 +1735,7 @@ static void migration_bitmap_sync(RAMState *rs) qemu_mutex_lock(&rs->bitmap_mutex); rcu_read_lock(); RAMBLOCK_FOREACH_NOT_IGNORED(block) { - migration_bitmap_sync_range(rs, block, 0, block->used_length); + migration_bitmap_sync_range(rs, block, block->used_length); } ram_counters.remaining = ram_bytes_remaining(); rcu_read_unlock(); @@ -4156,7 +4156,7 @@ static void colo_flush_ram_cache(void) memory_global_dirty_log_sync(); rcu_read_lock(); RAMBLOCK_FOREACH_NOT_IGNORED(block) { - migration_bitmap_sync_range(ram_state, block, 0, block->used_length); + migration_bitmap_sync_range(ram_state, block, block->used_length); } rcu_read_unlock(); -- 2.19.1 ^ permalink raw reply related [flat|nested] 33+ messages in thread
* [Qemu-devel] [PATCH 1/3] migration/ram.c: start of migration_bitmap_sync_range is always 0 2019-04-30 3:44 ` [Qemu-devel] [PATCH 1/3] migration/ram.c: start of migration_bitmap_sync_range is always 0 Wei Yang @ 2019-04-30 3:44 ` Wei Yang 2019-05-14 14:15 ` Dr. David Alan Gilbert 2019-05-14 14:27 ` Dr. David Alan Gilbert 2 siblings, 0 replies; 33+ messages in thread From: Wei Yang @ 2019-04-30 3:44 UTC (permalink / raw) To: qemu-devel; +Cc: pbonzini, Wei Yang, dgilbert, quintela We can eliminate to pass 0. Signed-off-by: Wei Yang <richardw.yang@linux.intel.com> --- migration/ram.c | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/migration/ram.c b/migration/ram.c index 35bd6213e9..9948b2d021 100644 --- a/migration/ram.c +++ b/migration/ram.c @@ -1643,10 +1643,10 @@ static inline bool migration_bitmap_clear_dirty(RAMState *rs, } static void migration_bitmap_sync_range(RAMState *rs, RAMBlock *rb, - ram_addr_t start, ram_addr_t length) + ram_addr_t length) { rs->migration_dirty_pages += - cpu_physical_memory_sync_dirty_bitmap(rb, start, length, + cpu_physical_memory_sync_dirty_bitmap(rb, 0, length, &rs->num_dirty_pages_period); } @@ -1735,7 +1735,7 @@ static void migration_bitmap_sync(RAMState *rs) qemu_mutex_lock(&rs->bitmap_mutex); rcu_read_lock(); RAMBLOCK_FOREACH_NOT_IGNORED(block) { - migration_bitmap_sync_range(rs, block, 0, block->used_length); + migration_bitmap_sync_range(rs, block, block->used_length); } ram_counters.remaining = ram_bytes_remaining(); rcu_read_unlock(); @@ -4156,7 +4156,7 @@ static void colo_flush_ram_cache(void) memory_global_dirty_log_sync(); rcu_read_lock(); RAMBLOCK_FOREACH_NOT_IGNORED(block) { - migration_bitmap_sync_range(ram_state, block, 0, block->used_length); + migration_bitmap_sync_range(ram_state, block, block->used_length); } rcu_read_unlock(); -- 2.19.1 ^ permalink raw reply related [flat|nested] 33+ messages in thread
* Re: [Qemu-devel] [PATCH 1/3] migration/ram.c: start of migration_bitmap_sync_range is always 0 2019-04-30 3:44 ` [Qemu-devel] [PATCH 1/3] migration/ram.c: start of migration_bitmap_sync_range is always 0 Wei Yang 2019-04-30 3:44 ` Wei Yang @ 2019-05-14 14:15 ` Dr. David Alan Gilbert 2019-05-14 14:27 ` Dr. David Alan Gilbert 2 siblings, 0 replies; 33+ messages in thread From: Dr. David Alan Gilbert @ 2019-05-14 14:15 UTC (permalink / raw) To: Wei Yang; +Cc: pbonzini, qemu-devel, quintela * Wei Yang (richardw.yang@linux.intel.com) wrote: > We can eliminate to pass 0. > > Signed-off-by: Wei Yang <richardw.yang@linux.intel.com> Reviewed-by: Dr. David Alan Gilbert <dgilbert@redhat.com> > --- > migration/ram.c | 8 ++++---- > 1 file changed, 4 insertions(+), 4 deletions(-) > > diff --git a/migration/ram.c b/migration/ram.c > index 35bd6213e9..9948b2d021 100644 > --- a/migration/ram.c > +++ b/migration/ram.c > @@ -1643,10 +1643,10 @@ static inline bool migration_bitmap_clear_dirty(RAMState *rs, > } > > static void migration_bitmap_sync_range(RAMState *rs, RAMBlock *rb, > - ram_addr_t start, ram_addr_t length) > + ram_addr_t length) > { > rs->migration_dirty_pages += > - cpu_physical_memory_sync_dirty_bitmap(rb, start, length, > + cpu_physical_memory_sync_dirty_bitmap(rb, 0, length, > &rs->num_dirty_pages_period); > } > > @@ -1735,7 +1735,7 @@ static void migration_bitmap_sync(RAMState *rs) > qemu_mutex_lock(&rs->bitmap_mutex); > rcu_read_lock(); > RAMBLOCK_FOREACH_NOT_IGNORED(block) { > - migration_bitmap_sync_range(rs, block, 0, block->used_length); > + migration_bitmap_sync_range(rs, block, block->used_length); > } > ram_counters.remaining = ram_bytes_remaining(); > rcu_read_unlock(); > @@ -4156,7 +4156,7 @@ static void colo_flush_ram_cache(void) > memory_global_dirty_log_sync(); > rcu_read_lock(); > RAMBLOCK_FOREACH_NOT_IGNORED(block) { > - migration_bitmap_sync_range(ram_state, block, 0, block->used_length); > + migration_bitmap_sync_range(ram_state, block, block->used_length); > } > rcu_read_unlock(); > > -- > 2.19.1 > -- Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [Qemu-devel] [PATCH 1/3] migration/ram.c: start of migration_bitmap_sync_range is always 0 2019-04-30 3:44 ` [Qemu-devel] [PATCH 1/3] migration/ram.c: start of migration_bitmap_sync_range is always 0 Wei Yang 2019-04-30 3:44 ` Wei Yang 2019-05-14 14:15 ` Dr. David Alan Gilbert @ 2019-05-14 14:27 ` Dr. David Alan Gilbert 2019-05-15 6:41 ` Wei Yang 2 siblings, 1 reply; 33+ messages in thread From: Dr. David Alan Gilbert @ 2019-05-14 14:27 UTC (permalink / raw) To: Wei Yang; +Cc: pbonzini, qemu-devel, quintela * Wei Yang (richardw.yang@linux.intel.com) wrote: > We can eliminate to pass 0. > > Signed-off-by: Wei Yang <richardw.yang@linux.intel.com> I'm going to queue just 1/3for the current pull. Dave > --- > migration/ram.c | 8 ++++---- > 1 file changed, 4 insertions(+), 4 deletions(-) > > diff --git a/migration/ram.c b/migration/ram.c > index 35bd6213e9..9948b2d021 100644 > --- a/migration/ram.c > +++ b/migration/ram.c > @@ -1643,10 +1643,10 @@ static inline bool migration_bitmap_clear_dirty(RAMState *rs, > } > > static void migration_bitmap_sync_range(RAMState *rs, RAMBlock *rb, > - ram_addr_t start, ram_addr_t length) > + ram_addr_t length) > { > rs->migration_dirty_pages += > - cpu_physical_memory_sync_dirty_bitmap(rb, start, length, > + cpu_physical_memory_sync_dirty_bitmap(rb, 0, length, > &rs->num_dirty_pages_period); > } > > @@ -1735,7 +1735,7 @@ static void migration_bitmap_sync(RAMState *rs) > qemu_mutex_lock(&rs->bitmap_mutex); > rcu_read_lock(); > RAMBLOCK_FOREACH_NOT_IGNORED(block) { > - migration_bitmap_sync_range(rs, block, 0, block->used_length); > + migration_bitmap_sync_range(rs, block, block->used_length); > } > ram_counters.remaining = ram_bytes_remaining(); > rcu_read_unlock(); > @@ -4156,7 +4156,7 @@ static void colo_flush_ram_cache(void) > memory_global_dirty_log_sync(); > rcu_read_lock(); > RAMBLOCK_FOREACH_NOT_IGNORED(block) { > - migration_bitmap_sync_range(ram_state, block, 0, block->used_length); > + migration_bitmap_sync_range(ram_state, block, block->used_length); > } > rcu_read_unlock(); > > -- > 2.19.1 > -- Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [Qemu-devel] [PATCH 1/3] migration/ram.c: start of migration_bitmap_sync_range is always 0 2019-05-14 14:27 ` Dr. David Alan Gilbert @ 2019-05-15 6:41 ` Wei Yang 2019-05-15 8:04 ` Dr. David Alan Gilbert 0 siblings, 1 reply; 33+ messages in thread From: Wei Yang @ 2019-05-15 6:41 UTC (permalink / raw) To: Dr. David Alan Gilbert; +Cc: pbonzini, quintela, Wei Yang, qemu-devel On Tue, May 14, 2019 at 03:27:02PM +0100, Dr. David Alan Gilbert wrote: >* Wei Yang (richardw.yang@linux.intel.com) wrote: >> We can eliminate to pass 0. >> >> Signed-off-by: Wei Yang <richardw.yang@linux.intel.com> > >I'm going to queue just 1/3for the current pull. In the pull request, I didn't see Patch[3]. Do I misunderstand this? > >Dave > -- Wei Yang Help you, Help me ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [Qemu-devel] [PATCH 1/3] migration/ram.c: start of migration_bitmap_sync_range is always 0 2019-05-15 6:41 ` Wei Yang @ 2019-05-15 8:04 ` Dr. David Alan Gilbert 2019-05-15 8:54 ` Wei Yang 0 siblings, 1 reply; 33+ messages in thread From: Dr. David Alan Gilbert @ 2019-05-15 8:04 UTC (permalink / raw) To: Wei Yang; +Cc: pbonzini, qemu-devel, quintela * Wei Yang (richardw.yang@linux.intel.com) wrote: > On Tue, May 14, 2019 at 03:27:02PM +0100, Dr. David Alan Gilbert wrote: > >* Wei Yang (richardw.yang@linux.intel.com) wrote: > >> We can eliminate to pass 0. > >> > >> Signed-off-by: Wei Yang <richardw.yang@linux.intel.com> > > > >I'm going to queue just 1/3for the current pull. > > In the pull request, I didn't see Patch[3]. Do I misunderstand this? Yes I meant only '[Patch 1/3]'. Dave > > > >Dave > > > > -- > Wei Yang > Help you, Help me -- Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [Qemu-devel] [PATCH 1/3] migration/ram.c: start of migration_bitmap_sync_range is always 0 2019-05-15 8:04 ` Dr. David Alan Gilbert @ 2019-05-15 8:54 ` Wei Yang 0 siblings, 0 replies; 33+ messages in thread From: Wei Yang @ 2019-05-15 8:54 UTC (permalink / raw) To: Dr. David Alan Gilbert; +Cc: pbonzini, quintela, Wei Yang, qemu-devel On Wed, May 15, 2019 at 09:04:51AM +0100, Dr. David Alan Gilbert wrote: >* Wei Yang (richardw.yang@linux.intel.com) wrote: >> On Tue, May 14, 2019 at 03:27:02PM +0100, Dr. David Alan Gilbert wrote: >> >* Wei Yang (richardw.yang@linux.intel.com) wrote: >> >> We can eliminate to pass 0. >> >> >> >> Signed-off-by: Wei Yang <richardw.yang@linux.intel.com> >> > >> >I'm going to queue just 1/3for the current pull. >> >> In the pull request, I didn't see Patch[3]. Do I misunderstand this? > >Yes I meant only '[Patch 1/3]'. Ah, thanks :-) > >Dave > >> > >> >Dave >> > >> >> -- >> Wei Yang >> Help you, Help me >-- >Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK -- Wei Yang Help you, Help me ^ permalink raw reply [flat|nested] 33+ messages in thread
* [Qemu-devel] [PATCH 2/3] migration/ram.c: start of cpu_physical_memory_sync_dirty_bitmap is always 0 2019-04-30 3:44 [Qemu-devel] [PATCH 0/3] Cleanup migration/ram.c Wei Yang 2019-04-30 3:44 ` Wei Yang 2019-04-30 3:44 ` [Qemu-devel] [PATCH 1/3] migration/ram.c: start of migration_bitmap_sync_range is always 0 Wei Yang @ 2019-04-30 3:44 ` Wei Yang 2019-04-30 3:44 ` Wei Yang 2019-05-14 14:21 ` Dr. David Alan Gilbert 2019-04-30 3:44 ` [Qemu-devel] [PATCH 3/3] ram: RAMBlock->offset is always aligned to a word Wei Yang ` (2 subsequent siblings) 5 siblings, 2 replies; 33+ messages in thread From: Wei Yang @ 2019-04-30 3:44 UTC (permalink / raw) To: qemu-devel; +Cc: pbonzini, quintela, dgilbert, Wei Yang Since start of cpu_physical_memory_sync_dirty_bitmap is always 0, we can remove this parameter and simplify the calculation a bit. Signed-off-by: Wei Yang <richardw.yang@linux.intel.com> --- include/exec/ram_addr.h | 15 ++++++--------- migration/ram.c | 2 +- 2 files changed, 7 insertions(+), 10 deletions(-) diff --git a/include/exec/ram_addr.h b/include/exec/ram_addr.h index 9ecd911c3e..3dfb2d52fb 100644 --- a/include/exec/ram_addr.h +++ b/include/exec/ram_addr.h @@ -409,18 +409,16 @@ static inline void cpu_physical_memory_clear_dirty_range(ram_addr_t start, static inline uint64_t cpu_physical_memory_sync_dirty_bitmap(RAMBlock *rb, - ram_addr_t start, ram_addr_t length, uint64_t *real_dirty_pages) { ram_addr_t addr; - unsigned long word = BIT_WORD((start + rb->offset) >> TARGET_PAGE_BITS); + unsigned long word = BIT_WORD(rb->offset >> TARGET_PAGE_BITS); uint64_t num_dirty = 0; unsigned long *dest = rb->bmap; - /* start address and length is aligned at the start of a word? */ - if (((word * BITS_PER_LONG) << TARGET_PAGE_BITS) == - (start + rb->offset) && + /* offset and length is aligned at the start of a word? */ + if (((word * BITS_PER_LONG) << TARGET_PAGE_BITS) == (rb->offset) && !(length & ((BITS_PER_LONG << TARGET_PAGE_BITS) - 1))) { int k; int nr = BITS_TO_LONGS(length >> TARGET_PAGE_BITS); @@ -428,14 +426,13 @@ uint64_t cpu_physical_memory_sync_dirty_bitmap(RAMBlock *rb, unsigned long idx = (word * BITS_PER_LONG) / DIRTY_MEMORY_BLOCK_SIZE; unsigned long offset = BIT_WORD((word * BITS_PER_LONG) % DIRTY_MEMORY_BLOCK_SIZE); - unsigned long page = BIT_WORD(start >> TARGET_PAGE_BITS); rcu_read_lock(); src = atomic_rcu_read( &ram_list.dirty_memory[DIRTY_MEMORY_MIGRATION])->blocks; - for (k = page; k < page + nr; k++) { + for (k = 0; k < nr; k++) { if (src[idx][offset]) { unsigned long bits = atomic_xchg(&src[idx][offset], 0); unsigned long new_dirty; @@ -458,11 +455,11 @@ uint64_t cpu_physical_memory_sync_dirty_bitmap(RAMBlock *rb, for (addr = 0; addr < length; addr += TARGET_PAGE_SIZE) { if (cpu_physical_memory_test_and_clear_dirty( - start + addr + offset, + addr + offset, TARGET_PAGE_SIZE, DIRTY_MEMORY_MIGRATION)) { *real_dirty_pages += 1; - long k = (start + addr) >> TARGET_PAGE_BITS; + long k = addr >> TARGET_PAGE_BITS; if (!test_and_set_bit(k, dest)) { num_dirty++; } diff --git a/migration/ram.c b/migration/ram.c index 9948b2d021..1def8122e9 100644 --- a/migration/ram.c +++ b/migration/ram.c @@ -1646,7 +1646,7 @@ static void migration_bitmap_sync_range(RAMState *rs, RAMBlock *rb, ram_addr_t length) { rs->migration_dirty_pages += - cpu_physical_memory_sync_dirty_bitmap(rb, 0, length, + cpu_physical_memory_sync_dirty_bitmap(rb, length, &rs->num_dirty_pages_period); } -- 2.19.1 ^ permalink raw reply related [flat|nested] 33+ messages in thread
* [Qemu-devel] [PATCH 2/3] migration/ram.c: start of cpu_physical_memory_sync_dirty_bitmap is always 0 2019-04-30 3:44 ` [Qemu-devel] [PATCH 2/3] migration/ram.c: start of cpu_physical_memory_sync_dirty_bitmap " Wei Yang @ 2019-04-30 3:44 ` Wei Yang 2019-05-14 14:21 ` Dr. David Alan Gilbert 1 sibling, 0 replies; 33+ messages in thread From: Wei Yang @ 2019-04-30 3:44 UTC (permalink / raw) To: qemu-devel; +Cc: pbonzini, Wei Yang, dgilbert, quintela Since start of cpu_physical_memory_sync_dirty_bitmap is always 0, we can remove this parameter and simplify the calculation a bit. Signed-off-by: Wei Yang <richardw.yang@linux.intel.com> --- include/exec/ram_addr.h | 15 ++++++--------- migration/ram.c | 2 +- 2 files changed, 7 insertions(+), 10 deletions(-) diff --git a/include/exec/ram_addr.h b/include/exec/ram_addr.h index 9ecd911c3e..3dfb2d52fb 100644 --- a/include/exec/ram_addr.h +++ b/include/exec/ram_addr.h @@ -409,18 +409,16 @@ static inline void cpu_physical_memory_clear_dirty_range(ram_addr_t start, static inline uint64_t cpu_physical_memory_sync_dirty_bitmap(RAMBlock *rb, - ram_addr_t start, ram_addr_t length, uint64_t *real_dirty_pages) { ram_addr_t addr; - unsigned long word = BIT_WORD((start + rb->offset) >> TARGET_PAGE_BITS); + unsigned long word = BIT_WORD(rb->offset >> TARGET_PAGE_BITS); uint64_t num_dirty = 0; unsigned long *dest = rb->bmap; - /* start address and length is aligned at the start of a word? */ - if (((word * BITS_PER_LONG) << TARGET_PAGE_BITS) == - (start + rb->offset) && + /* offset and length is aligned at the start of a word? */ + if (((word * BITS_PER_LONG) << TARGET_PAGE_BITS) == (rb->offset) && !(length & ((BITS_PER_LONG << TARGET_PAGE_BITS) - 1))) { int k; int nr = BITS_TO_LONGS(length >> TARGET_PAGE_BITS); @@ -428,14 +426,13 @@ uint64_t cpu_physical_memory_sync_dirty_bitmap(RAMBlock *rb, unsigned long idx = (word * BITS_PER_LONG) / DIRTY_MEMORY_BLOCK_SIZE; unsigned long offset = BIT_WORD((word * BITS_PER_LONG) % DIRTY_MEMORY_BLOCK_SIZE); - unsigned long page = BIT_WORD(start >> TARGET_PAGE_BITS); rcu_read_lock(); src = atomic_rcu_read( &ram_list.dirty_memory[DIRTY_MEMORY_MIGRATION])->blocks; - for (k = page; k < page + nr; k++) { + for (k = 0; k < nr; k++) { if (src[idx][offset]) { unsigned long bits = atomic_xchg(&src[idx][offset], 0); unsigned long new_dirty; @@ -458,11 +455,11 @@ uint64_t cpu_physical_memory_sync_dirty_bitmap(RAMBlock *rb, for (addr = 0; addr < length; addr += TARGET_PAGE_SIZE) { if (cpu_physical_memory_test_and_clear_dirty( - start + addr + offset, + addr + offset, TARGET_PAGE_SIZE, DIRTY_MEMORY_MIGRATION)) { *real_dirty_pages += 1; - long k = (start + addr) >> TARGET_PAGE_BITS; + long k = addr >> TARGET_PAGE_BITS; if (!test_and_set_bit(k, dest)) { num_dirty++; } diff --git a/migration/ram.c b/migration/ram.c index 9948b2d021..1def8122e9 100644 --- a/migration/ram.c +++ b/migration/ram.c @@ -1646,7 +1646,7 @@ static void migration_bitmap_sync_range(RAMState *rs, RAMBlock *rb, ram_addr_t length) { rs->migration_dirty_pages += - cpu_physical_memory_sync_dirty_bitmap(rb, 0, length, + cpu_physical_memory_sync_dirty_bitmap(rb, length, &rs->num_dirty_pages_period); } -- 2.19.1 ^ permalink raw reply related [flat|nested] 33+ messages in thread
* Re: [Qemu-devel] [PATCH 2/3] migration/ram.c: start of cpu_physical_memory_sync_dirty_bitmap is always 0 2019-04-30 3:44 ` [Qemu-devel] [PATCH 2/3] migration/ram.c: start of cpu_physical_memory_sync_dirty_bitmap " Wei Yang 2019-04-30 3:44 ` Wei Yang @ 2019-05-14 14:21 ` Dr. David Alan Gilbert 2019-05-31 0:54 ` Wei Yang ` (2 more replies) 1 sibling, 3 replies; 33+ messages in thread From: Dr. David Alan Gilbert @ 2019-05-14 14:21 UTC (permalink / raw) To: Wei Yang, pbonzini; +Cc: qemu-devel, quintela * Wei Yang (richardw.yang@linux.intel.com) wrote: > Since start of cpu_physical_memory_sync_dirty_bitmap is always 0, we can > remove this parameter and simplify the calculation a bit. > > Signed-off-by: Wei Yang <richardw.yang@linux.intel.com> So I think you're right it's currently unused; however, lets ask Paolo: Do we need to keep this parameter for flexiblity? Dave > --- > include/exec/ram_addr.h | 15 ++++++--------- > migration/ram.c | 2 +- > 2 files changed, 7 insertions(+), 10 deletions(-) > > diff --git a/include/exec/ram_addr.h b/include/exec/ram_addr.h > index 9ecd911c3e..3dfb2d52fb 100644 > --- a/include/exec/ram_addr.h > +++ b/include/exec/ram_addr.h > @@ -409,18 +409,16 @@ static inline void cpu_physical_memory_clear_dirty_range(ram_addr_t start, > > static inline > uint64_t cpu_physical_memory_sync_dirty_bitmap(RAMBlock *rb, > - ram_addr_t start, > ram_addr_t length, > uint64_t *real_dirty_pages) > { > ram_addr_t addr; > - unsigned long word = BIT_WORD((start + rb->offset) >> TARGET_PAGE_BITS); > + unsigned long word = BIT_WORD(rb->offset >> TARGET_PAGE_BITS); > uint64_t num_dirty = 0; > unsigned long *dest = rb->bmap; > > - /* start address and length is aligned at the start of a word? */ > - if (((word * BITS_PER_LONG) << TARGET_PAGE_BITS) == > - (start + rb->offset) && > + /* offset and length is aligned at the start of a word? */ > + if (((word * BITS_PER_LONG) << TARGET_PAGE_BITS) == (rb->offset) && > !(length & ((BITS_PER_LONG << TARGET_PAGE_BITS) - 1))) { > int k; > int nr = BITS_TO_LONGS(length >> TARGET_PAGE_BITS); > @@ -428,14 +426,13 @@ uint64_t cpu_physical_memory_sync_dirty_bitmap(RAMBlock *rb, > unsigned long idx = (word * BITS_PER_LONG) / DIRTY_MEMORY_BLOCK_SIZE; > unsigned long offset = BIT_WORD((word * BITS_PER_LONG) % > DIRTY_MEMORY_BLOCK_SIZE); > - unsigned long page = BIT_WORD(start >> TARGET_PAGE_BITS); > > rcu_read_lock(); > > src = atomic_rcu_read( > &ram_list.dirty_memory[DIRTY_MEMORY_MIGRATION])->blocks; > > - for (k = page; k < page + nr; k++) { > + for (k = 0; k < nr; k++) { > if (src[idx][offset]) { > unsigned long bits = atomic_xchg(&src[idx][offset], 0); > unsigned long new_dirty; > @@ -458,11 +455,11 @@ uint64_t cpu_physical_memory_sync_dirty_bitmap(RAMBlock *rb, > > for (addr = 0; addr < length; addr += TARGET_PAGE_SIZE) { > if (cpu_physical_memory_test_and_clear_dirty( > - start + addr + offset, > + addr + offset, > TARGET_PAGE_SIZE, > DIRTY_MEMORY_MIGRATION)) { > *real_dirty_pages += 1; > - long k = (start + addr) >> TARGET_PAGE_BITS; > + long k = addr >> TARGET_PAGE_BITS; > if (!test_and_set_bit(k, dest)) { > num_dirty++; > } > diff --git a/migration/ram.c b/migration/ram.c > index 9948b2d021..1def8122e9 100644 > --- a/migration/ram.c > +++ b/migration/ram.c > @@ -1646,7 +1646,7 @@ static void migration_bitmap_sync_range(RAMState *rs, RAMBlock *rb, > ram_addr_t length) > { > rs->migration_dirty_pages += > - cpu_physical_memory_sync_dirty_bitmap(rb, 0, length, > + cpu_physical_memory_sync_dirty_bitmap(rb, length, > &rs->num_dirty_pages_period); > } > > -- > 2.19.1 > -- Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [Qemu-devel] [PATCH 2/3] migration/ram.c: start of cpu_physical_memory_sync_dirty_bitmap is always 0 2019-05-14 14:21 ` Dr. David Alan Gilbert @ 2019-05-31 0:54 ` Wei Yang 2019-06-21 7:43 ` Wei Yang 2019-07-17 1:13 ` Wei Yang 2 siblings, 0 replies; 33+ messages in thread From: Wei Yang @ 2019-05-31 0:54 UTC (permalink / raw) To: Dr. David Alan Gilbert; +Cc: pbonzini, quintela, Wei Yang, qemu-devel On Tue, May 14, 2019 at 03:21:08PM +0100, Dr. David Alan Gilbert wrote: >* Wei Yang (richardw.yang@linux.intel.com) wrote: >> Since start of cpu_physical_memory_sync_dirty_bitmap is always 0, we can >> remove this parameter and simplify the calculation a bit. >> >> Signed-off-by: Wei Yang <richardw.yang@linux.intel.com> > >So I think you're right it's currently unused; however, lets ask >Paolo: Do we need to keep this parameter for flexiblity? > Hi Paolo Do you like this one? >Dave > >> --- >> include/exec/ram_addr.h | 15 ++++++--------- >> migration/ram.c | 2 +- >> 2 files changed, 7 insertions(+), 10 deletions(-) >> >> diff --git a/include/exec/ram_addr.h b/include/exec/ram_addr.h >> index 9ecd911c3e..3dfb2d52fb 100644 >> --- a/include/exec/ram_addr.h >> +++ b/include/exec/ram_addr.h >> @@ -409,18 +409,16 @@ static inline void cpu_physical_memory_clear_dirty_range(ram_addr_t start, >> >> static inline >> uint64_t cpu_physical_memory_sync_dirty_bitmap(RAMBlock *rb, >> - ram_addr_t start, >> ram_addr_t length, >> uint64_t *real_dirty_pages) >> { >> ram_addr_t addr; >> - unsigned long word = BIT_WORD((start + rb->offset) >> TARGET_PAGE_BITS); >> + unsigned long word = BIT_WORD(rb->offset >> TARGET_PAGE_BITS); >> uint64_t num_dirty = 0; >> unsigned long *dest = rb->bmap; >> >> - /* start address and length is aligned at the start of a word? */ >> - if (((word * BITS_PER_LONG) << TARGET_PAGE_BITS) == >> - (start + rb->offset) && >> + /* offset and length is aligned at the start of a word? */ >> + if (((word * BITS_PER_LONG) << TARGET_PAGE_BITS) == (rb->offset) && >> !(length & ((BITS_PER_LONG << TARGET_PAGE_BITS) - 1))) { >> int k; >> int nr = BITS_TO_LONGS(length >> TARGET_PAGE_BITS); >> @@ -428,14 +426,13 @@ uint64_t cpu_physical_memory_sync_dirty_bitmap(RAMBlock *rb, >> unsigned long idx = (word * BITS_PER_LONG) / DIRTY_MEMORY_BLOCK_SIZE; >> unsigned long offset = BIT_WORD((word * BITS_PER_LONG) % >> DIRTY_MEMORY_BLOCK_SIZE); >> - unsigned long page = BIT_WORD(start >> TARGET_PAGE_BITS); >> >> rcu_read_lock(); >> >> src = atomic_rcu_read( >> &ram_list.dirty_memory[DIRTY_MEMORY_MIGRATION])->blocks; >> >> - for (k = page; k < page + nr; k++) { >> + for (k = 0; k < nr; k++) { >> if (src[idx][offset]) { >> unsigned long bits = atomic_xchg(&src[idx][offset], 0); >> unsigned long new_dirty; >> @@ -458,11 +455,11 @@ uint64_t cpu_physical_memory_sync_dirty_bitmap(RAMBlock *rb, >> >> for (addr = 0; addr < length; addr += TARGET_PAGE_SIZE) { >> if (cpu_physical_memory_test_and_clear_dirty( >> - start + addr + offset, >> + addr + offset, >> TARGET_PAGE_SIZE, >> DIRTY_MEMORY_MIGRATION)) { >> *real_dirty_pages += 1; >> - long k = (start + addr) >> TARGET_PAGE_BITS; >> + long k = addr >> TARGET_PAGE_BITS; >> if (!test_and_set_bit(k, dest)) { >> num_dirty++; >> } >> diff --git a/migration/ram.c b/migration/ram.c >> index 9948b2d021..1def8122e9 100644 >> --- a/migration/ram.c >> +++ b/migration/ram.c >> @@ -1646,7 +1646,7 @@ static void migration_bitmap_sync_range(RAMState *rs, RAMBlock *rb, >> ram_addr_t length) >> { >> rs->migration_dirty_pages += >> - cpu_physical_memory_sync_dirty_bitmap(rb, 0, length, >> + cpu_physical_memory_sync_dirty_bitmap(rb, length, >> &rs->num_dirty_pages_period); >> } >> >> -- >> 2.19.1 >> >-- >Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK -- Wei Yang Help you, Help me ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [Qemu-devel] [PATCH 2/3] migration/ram.c: start of cpu_physical_memory_sync_dirty_bitmap is always 0 2019-05-14 14:21 ` Dr. David Alan Gilbert 2019-05-31 0:54 ` Wei Yang @ 2019-06-21 7:43 ` Wei Yang 2019-07-17 1:13 ` Wei Yang 2 siblings, 0 replies; 33+ messages in thread From: Wei Yang @ 2019-06-21 7:43 UTC (permalink / raw) To: Dr. David Alan Gilbert; +Cc: pbonzini, quintela, Wei Yang, qemu-devel On Tue, May 14, 2019 at 03:21:08PM +0100, Dr. David Alan Gilbert wrote: >* Wei Yang (richardw.yang@linux.intel.com) wrote: >> Since start of cpu_physical_memory_sync_dirty_bitmap is always 0, we can >> remove this parameter and simplify the calculation a bit. >> >> Signed-off-by: Wei Yang <richardw.yang@linux.intel.com> > >So I think you're right it's currently unused; however, lets ask >Paolo: Do we need to keep this parameter for flexiblity? > Hi, Paolo, Have time to take a look? >Dave > >> --- >> include/exec/ram_addr.h | 15 ++++++--------- >> migration/ram.c | 2 +- >> 2 files changed, 7 insertions(+), 10 deletions(-) >> >> diff --git a/include/exec/ram_addr.h b/include/exec/ram_addr.h >> index 9ecd911c3e..3dfb2d52fb 100644 >> --- a/include/exec/ram_addr.h >> +++ b/include/exec/ram_addr.h >> @@ -409,18 +409,16 @@ static inline void cpu_physical_memory_clear_dirty_range(ram_addr_t start, >> >> static inline >> uint64_t cpu_physical_memory_sync_dirty_bitmap(RAMBlock *rb, >> - ram_addr_t start, >> ram_addr_t length, >> uint64_t *real_dirty_pages) >> { >> ram_addr_t addr; >> - unsigned long word = BIT_WORD((start + rb->offset) >> TARGET_PAGE_BITS); >> + unsigned long word = BIT_WORD(rb->offset >> TARGET_PAGE_BITS); >> uint64_t num_dirty = 0; >> unsigned long *dest = rb->bmap; >> >> - /* start address and length is aligned at the start of a word? */ >> - if (((word * BITS_PER_LONG) << TARGET_PAGE_BITS) == >> - (start + rb->offset) && >> + /* offset and length is aligned at the start of a word? */ >> + if (((word * BITS_PER_LONG) << TARGET_PAGE_BITS) == (rb->offset) && >> !(length & ((BITS_PER_LONG << TARGET_PAGE_BITS) - 1))) { >> int k; >> int nr = BITS_TO_LONGS(length >> TARGET_PAGE_BITS); >> @@ -428,14 +426,13 @@ uint64_t cpu_physical_memory_sync_dirty_bitmap(RAMBlock *rb, >> unsigned long idx = (word * BITS_PER_LONG) / DIRTY_MEMORY_BLOCK_SIZE; >> unsigned long offset = BIT_WORD((word * BITS_PER_LONG) % >> DIRTY_MEMORY_BLOCK_SIZE); >> - unsigned long page = BIT_WORD(start >> TARGET_PAGE_BITS); >> >> rcu_read_lock(); >> >> src = atomic_rcu_read( >> &ram_list.dirty_memory[DIRTY_MEMORY_MIGRATION])->blocks; >> >> - for (k = page; k < page + nr; k++) { >> + for (k = 0; k < nr; k++) { >> if (src[idx][offset]) { >> unsigned long bits = atomic_xchg(&src[idx][offset], 0); >> unsigned long new_dirty; >> @@ -458,11 +455,11 @@ uint64_t cpu_physical_memory_sync_dirty_bitmap(RAMBlock *rb, >> >> for (addr = 0; addr < length; addr += TARGET_PAGE_SIZE) { >> if (cpu_physical_memory_test_and_clear_dirty( >> - start + addr + offset, >> + addr + offset, >> TARGET_PAGE_SIZE, >> DIRTY_MEMORY_MIGRATION)) { >> *real_dirty_pages += 1; >> - long k = (start + addr) >> TARGET_PAGE_BITS; >> + long k = addr >> TARGET_PAGE_BITS; >> if (!test_and_set_bit(k, dest)) { >> num_dirty++; >> } >> diff --git a/migration/ram.c b/migration/ram.c >> index 9948b2d021..1def8122e9 100644 >> --- a/migration/ram.c >> +++ b/migration/ram.c >> @@ -1646,7 +1646,7 @@ static void migration_bitmap_sync_range(RAMState *rs, RAMBlock *rb, >> ram_addr_t length) >> { >> rs->migration_dirty_pages += >> - cpu_physical_memory_sync_dirty_bitmap(rb, 0, length, >> + cpu_physical_memory_sync_dirty_bitmap(rb, length, >> &rs->num_dirty_pages_period); >> } >> >> -- >> 2.19.1 >> >-- >Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK -- Wei Yang Help you, Help me ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [Qemu-devel] [PATCH 2/3] migration/ram.c: start of cpu_physical_memory_sync_dirty_bitmap is always 0 2019-05-14 14:21 ` Dr. David Alan Gilbert 2019-05-31 0:54 ` Wei Yang 2019-06-21 7:43 ` Wei Yang @ 2019-07-17 1:13 ` Wei Yang 2019-07-17 9:16 ` Paolo Bonzini 2 siblings, 1 reply; 33+ messages in thread From: Wei Yang @ 2019-07-17 1:13 UTC (permalink / raw) To: Dr. David Alan Gilbert; +Cc: pbonzini, quintela, Wei Yang, qemu-devel On Tue, May 14, 2019 at 03:21:08PM +0100, Dr. David Alan Gilbert wrote: >* Wei Yang (richardw.yang@linux.intel.com) wrote: >> Since start of cpu_physical_memory_sync_dirty_bitmap is always 0, we can >> remove this parameter and simplify the calculation a bit. >> >> Signed-off-by: Wei Yang <richardw.yang@linux.intel.com> > >So I think you're right it's currently unused; however, lets ask >Paolo: Do we need to keep this parameter for flexiblity? > Hey, Paolo Do you have some spare time to give some insight? >Dave > >> --- >> include/exec/ram_addr.h | 15 ++++++--------- >> migration/ram.c | 2 +- >> 2 files changed, 7 insertions(+), 10 deletions(-) >> >> diff --git a/include/exec/ram_addr.h b/include/exec/ram_addr.h >> index 9ecd911c3e..3dfb2d52fb 100644 >> --- a/include/exec/ram_addr.h >> +++ b/include/exec/ram_addr.h >> @@ -409,18 +409,16 @@ static inline void cpu_physical_memory_clear_dirty_range(ram_addr_t start, >> >> static inline >> uint64_t cpu_physical_memory_sync_dirty_bitmap(RAMBlock *rb, >> - ram_addr_t start, >> ram_addr_t length, >> uint64_t *real_dirty_pages) >> { >> ram_addr_t addr; >> - unsigned long word = BIT_WORD((start + rb->offset) >> TARGET_PAGE_BITS); >> + unsigned long word = BIT_WORD(rb->offset >> TARGET_PAGE_BITS); >> uint64_t num_dirty = 0; >> unsigned long *dest = rb->bmap; >> >> - /* start address and length is aligned at the start of a word? */ >> - if (((word * BITS_PER_LONG) << TARGET_PAGE_BITS) == >> - (start + rb->offset) && >> + /* offset and length is aligned at the start of a word? */ >> + if (((word * BITS_PER_LONG) << TARGET_PAGE_BITS) == (rb->offset) && >> !(length & ((BITS_PER_LONG << TARGET_PAGE_BITS) - 1))) { >> int k; >> int nr = BITS_TO_LONGS(length >> TARGET_PAGE_BITS); >> @@ -428,14 +426,13 @@ uint64_t cpu_physical_memory_sync_dirty_bitmap(RAMBlock *rb, >> unsigned long idx = (word * BITS_PER_LONG) / DIRTY_MEMORY_BLOCK_SIZE; >> unsigned long offset = BIT_WORD((word * BITS_PER_LONG) % >> DIRTY_MEMORY_BLOCK_SIZE); >> - unsigned long page = BIT_WORD(start >> TARGET_PAGE_BITS); >> >> rcu_read_lock(); >> >> src = atomic_rcu_read( >> &ram_list.dirty_memory[DIRTY_MEMORY_MIGRATION])->blocks; >> >> - for (k = page; k < page + nr; k++) { >> + for (k = 0; k < nr; k++) { >> if (src[idx][offset]) { >> unsigned long bits = atomic_xchg(&src[idx][offset], 0); >> unsigned long new_dirty; >> @@ -458,11 +455,11 @@ uint64_t cpu_physical_memory_sync_dirty_bitmap(RAMBlock *rb, >> >> for (addr = 0; addr < length; addr += TARGET_PAGE_SIZE) { >> if (cpu_physical_memory_test_and_clear_dirty( >> - start + addr + offset, >> + addr + offset, >> TARGET_PAGE_SIZE, >> DIRTY_MEMORY_MIGRATION)) { >> *real_dirty_pages += 1; >> - long k = (start + addr) >> TARGET_PAGE_BITS; >> + long k = addr >> TARGET_PAGE_BITS; >> if (!test_and_set_bit(k, dest)) { >> num_dirty++; >> } >> diff --git a/migration/ram.c b/migration/ram.c >> index 9948b2d021..1def8122e9 100644 >> --- a/migration/ram.c >> +++ b/migration/ram.c >> @@ -1646,7 +1646,7 @@ static void migration_bitmap_sync_range(RAMState *rs, RAMBlock *rb, >> ram_addr_t length) >> { >> rs->migration_dirty_pages += >> - cpu_physical_memory_sync_dirty_bitmap(rb, 0, length, >> + cpu_physical_memory_sync_dirty_bitmap(rb, length, >> &rs->num_dirty_pages_period); >> } >> >> -- >> 2.19.1 >> >-- >Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK -- Wei Yang Help you, Help me ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [Qemu-devel] [PATCH 2/3] migration/ram.c: start of cpu_physical_memory_sync_dirty_bitmap is always 0 2019-07-17 1:13 ` Wei Yang @ 2019-07-17 9:16 ` Paolo Bonzini 2019-07-18 1:07 ` Wei Yang 0 siblings, 1 reply; 33+ messages in thread From: Paolo Bonzini @ 2019-07-17 9:16 UTC (permalink / raw) To: Wei Yang, Dr. David Alan Gilbert; +Cc: qemu-devel, quintela On 17/07/19 03:13, Wei Yang wrote: > On Tue, May 14, 2019 at 03:21:08PM +0100, Dr. David Alan Gilbert wrote: >> * Wei Yang (richardw.yang@linux.intel.com) wrote: >>> Since start of cpu_physical_memory_sync_dirty_bitmap is always 0, we can >>> remove this parameter and simplify the calculation a bit. >>> >>> Signed-off-by: Wei Yang <richardw.yang@linux.intel.com> >> >> So I think you're right it's currently unused; however, lets ask >> Paolo: Do we need to keep this parameter for flexiblity? >> > > Hey, Paolo > > Do you have some spare time to give some insight? I think it's cleaner to leave the start argument in place. However, I'll note that in migration_bitmap_sync_range the length argument is always block->used_length so that's also unnecessary (you already have block). Paolo >> Dave >> >>> --- >>> include/exec/ram_addr.h | 15 ++++++--------- >>> migration/ram.c | 2 +- >>> 2 files changed, 7 insertions(+), 10 deletions(-) >>> >>> diff --git a/include/exec/ram_addr.h b/include/exec/ram_addr.h >>> index 9ecd911c3e..3dfb2d52fb 100644 >>> --- a/include/exec/ram_addr.h >>> +++ b/include/exec/ram_addr.h >>> @@ -409,18 +409,16 @@ static inline void cpu_physical_memory_clear_dirty_range(ram_addr_t start, >>> >>> static inline >>> uint64_t cpu_physical_memory_sync_dirty_bitmap(RAMBlock *rb, >>> - ram_addr_t start, >>> ram_addr_t length, >>> uint64_t *real_dirty_pages) >>> { >>> ram_addr_t addr; >>> - unsigned long word = BIT_WORD((start + rb->offset) >> TARGET_PAGE_BITS); >>> + unsigned long word = BIT_WORD(rb->offset >> TARGET_PAGE_BITS); >>> uint64_t num_dirty = 0; >>> unsigned long *dest = rb->bmap; >>> >>> - /* start address and length is aligned at the start of a word? */ >>> - if (((word * BITS_PER_LONG) << TARGET_PAGE_BITS) == >>> - (start + rb->offset) && >>> + /* offset and length is aligned at the start of a word? */ >>> + if (((word * BITS_PER_LONG) << TARGET_PAGE_BITS) == (rb->offset) && >>> !(length & ((BITS_PER_LONG << TARGET_PAGE_BITS) - 1))) { >>> int k; >>> int nr = BITS_TO_LONGS(length >> TARGET_PAGE_BITS); >>> @@ -428,14 +426,13 @@ uint64_t cpu_physical_memory_sync_dirty_bitmap(RAMBlock *rb, >>> unsigned long idx = (word * BITS_PER_LONG) / DIRTY_MEMORY_BLOCK_SIZE; >>> unsigned long offset = BIT_WORD((word * BITS_PER_LONG) % >>> DIRTY_MEMORY_BLOCK_SIZE); >>> - unsigned long page = BIT_WORD(start >> TARGET_PAGE_BITS); >>> >>> rcu_read_lock(); >>> >>> src = atomic_rcu_read( >>> &ram_list.dirty_memory[DIRTY_MEMORY_MIGRATION])->blocks; >>> >>> - for (k = page; k < page + nr; k++) { >>> + for (k = 0; k < nr; k++) { >>> if (src[idx][offset]) { >>> unsigned long bits = atomic_xchg(&src[idx][offset], 0); >>> unsigned long new_dirty; >>> @@ -458,11 +455,11 @@ uint64_t cpu_physical_memory_sync_dirty_bitmap(RAMBlock *rb, >>> >>> for (addr = 0; addr < length; addr += TARGET_PAGE_SIZE) { >>> if (cpu_physical_memory_test_and_clear_dirty( >>> - start + addr + offset, >>> + addr + offset, >>> TARGET_PAGE_SIZE, >>> DIRTY_MEMORY_MIGRATION)) { >>> *real_dirty_pages += 1; >>> - long k = (start + addr) >> TARGET_PAGE_BITS; >>> + long k = addr >> TARGET_PAGE_BITS; >>> if (!test_and_set_bit(k, dest)) { >>> num_dirty++; >>> } >>> diff --git a/migration/ram.c b/migration/ram.c >>> index 9948b2d021..1def8122e9 100644 >>> --- a/migration/ram.c >>> +++ b/migration/ram.c >>> @@ -1646,7 +1646,7 @@ static void migration_bitmap_sync_range(RAMState *rs, RAMBlock *rb, >>> ram_addr_t length) >>> { >>> rs->migration_dirty_pages += >>> - cpu_physical_memory_sync_dirty_bitmap(rb, 0, length, >>> + cpu_physical_memory_sync_dirty_bitmap(rb, length, >>> &rs->num_dirty_pages_period); >>> } >>> >>> -- >>> 2.19.1 >>> >> -- >> Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK > ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [Qemu-devel] [PATCH 2/3] migration/ram.c: start of cpu_physical_memory_sync_dirty_bitmap is always 0 2019-07-17 9:16 ` Paolo Bonzini @ 2019-07-18 1:07 ` Wei Yang 0 siblings, 0 replies; 33+ messages in thread From: Wei Yang @ 2019-07-18 1:07 UTC (permalink / raw) To: Paolo Bonzini; +Cc: qemu-devel, quintela, Wei Yang, Dr. David Alan Gilbert On Wed, Jul 17, 2019 at 11:16:19AM +0200, Paolo Bonzini wrote: >On 17/07/19 03:13, Wei Yang wrote: >> On Tue, May 14, 2019 at 03:21:08PM +0100, Dr. David Alan Gilbert wrote: >>> * Wei Yang (richardw.yang@linux.intel.com) wrote: >>>> Since start of cpu_physical_memory_sync_dirty_bitmap is always 0, we can >>>> remove this parameter and simplify the calculation a bit. >>>> >>>> Signed-off-by: Wei Yang <richardw.yang@linux.intel.com> >>> >>> So I think you're right it's currently unused; however, lets ask >>> Paolo: Do we need to keep this parameter for flexiblity? >>> >> >> Hey, Paolo >> >> Do you have some spare time to give some insight? > >I think it's cleaner to leave the start argument in place. However, >I'll note that in migration_bitmap_sync_range the length argument is >always block->used_length so that's also unnecessary (you already have >block). > That's reasonable. >Paolo > -- Wei Yang Help you, Help me ^ permalink raw reply [flat|nested] 33+ messages in thread
* [Qemu-devel] [PATCH 3/3] ram: RAMBlock->offset is always aligned to a word 2019-04-30 3:44 [Qemu-devel] [PATCH 0/3] Cleanup migration/ram.c Wei Yang ` (2 preceding siblings ...) 2019-04-30 3:44 ` [Qemu-devel] [PATCH 2/3] migration/ram.c: start of cpu_physical_memory_sync_dirty_bitmap " Wei Yang @ 2019-04-30 3:44 ` Wei Yang 2019-04-30 3:44 ` Wei Yang 2019-07-17 9:17 ` Paolo Bonzini 2019-05-01 22:53 ` [Qemu-devel] [PATCH 0/3] Cleanup migration/ram.c no-reply 2019-05-02 4:24 ` no-reply 5 siblings, 2 replies; 33+ messages in thread From: Wei Yang @ 2019-04-30 3:44 UTC (permalink / raw) To: qemu-devel; +Cc: pbonzini, quintela, dgilbert, Wei Yang RAMBlock->offset is calculated by find_ram_offset, which makes sure the offset is aligned to a word. This patch removes the alignment check on offset and unnecessary variable *word*. Signed-off-by: Wei Yang <richardw.yang@linux.intel.com> --- include/exec/ram_addr.h | 15 +++++++++------ 1 file changed, 9 insertions(+), 6 deletions(-) diff --git a/include/exec/ram_addr.h b/include/exec/ram_addr.h index 3dfb2d52fb..a7c81bdb32 100644 --- a/include/exec/ram_addr.h +++ b/include/exec/ram_addr.h @@ -413,18 +413,21 @@ uint64_t cpu_physical_memory_sync_dirty_bitmap(RAMBlock *rb, uint64_t *real_dirty_pages) { ram_addr_t addr; - unsigned long word = BIT_WORD(rb->offset >> TARGET_PAGE_BITS); uint64_t num_dirty = 0; unsigned long *dest = rb->bmap; - /* offset and length is aligned at the start of a word? */ - if (((word * BITS_PER_LONG) << TARGET_PAGE_BITS) == (rb->offset) && - !(length & ((BITS_PER_LONG << TARGET_PAGE_BITS) - 1))) { + /* + * Since RAMBlock->offset is guaranteed to be aligned to a word by + * find_ram_offset(), if length is aligned at the start of a word, go the + * fast path. + */ + if (!(length & ((BITS_PER_LONG << TARGET_PAGE_BITS) - 1))) { int k; int nr = BITS_TO_LONGS(length >> TARGET_PAGE_BITS); unsigned long * const *src; - unsigned long idx = (word * BITS_PER_LONG) / DIRTY_MEMORY_BLOCK_SIZE; - unsigned long offset = BIT_WORD((word * BITS_PER_LONG) % + unsigned long idx = (rb->offset >> TARGET_PAGE_BITS) / + DIRTY_MEMORY_BLOCK_SIZE; + unsigned long offset = BIT_WORD((rb->offset >> TARGET_PAGE_BITS) % DIRTY_MEMORY_BLOCK_SIZE); rcu_read_lock(); -- 2.19.1 ^ permalink raw reply related [flat|nested] 33+ messages in thread
* [Qemu-devel] [PATCH 3/3] ram: RAMBlock->offset is always aligned to a word 2019-04-30 3:44 ` [Qemu-devel] [PATCH 3/3] ram: RAMBlock->offset is always aligned to a word Wei Yang @ 2019-04-30 3:44 ` Wei Yang 2019-07-17 9:17 ` Paolo Bonzini 1 sibling, 0 replies; 33+ messages in thread From: Wei Yang @ 2019-04-30 3:44 UTC (permalink / raw) To: qemu-devel; +Cc: pbonzini, Wei Yang, dgilbert, quintela RAMBlock->offset is calculated by find_ram_offset, which makes sure the offset is aligned to a word. This patch removes the alignment check on offset and unnecessary variable *word*. Signed-off-by: Wei Yang <richardw.yang@linux.intel.com> --- include/exec/ram_addr.h | 15 +++++++++------ 1 file changed, 9 insertions(+), 6 deletions(-) diff --git a/include/exec/ram_addr.h b/include/exec/ram_addr.h index 3dfb2d52fb..a7c81bdb32 100644 --- a/include/exec/ram_addr.h +++ b/include/exec/ram_addr.h @@ -413,18 +413,21 @@ uint64_t cpu_physical_memory_sync_dirty_bitmap(RAMBlock *rb, uint64_t *real_dirty_pages) { ram_addr_t addr; - unsigned long word = BIT_WORD(rb->offset >> TARGET_PAGE_BITS); uint64_t num_dirty = 0; unsigned long *dest = rb->bmap; - /* offset and length is aligned at the start of a word? */ - if (((word * BITS_PER_LONG) << TARGET_PAGE_BITS) == (rb->offset) && - !(length & ((BITS_PER_LONG << TARGET_PAGE_BITS) - 1))) { + /* + * Since RAMBlock->offset is guaranteed to be aligned to a word by + * find_ram_offset(), if length is aligned at the start of a word, go the + * fast path. + */ + if (!(length & ((BITS_PER_LONG << TARGET_PAGE_BITS) - 1))) { int k; int nr = BITS_TO_LONGS(length >> TARGET_PAGE_BITS); unsigned long * const *src; - unsigned long idx = (word * BITS_PER_LONG) / DIRTY_MEMORY_BLOCK_SIZE; - unsigned long offset = BIT_WORD((word * BITS_PER_LONG) % + unsigned long idx = (rb->offset >> TARGET_PAGE_BITS) / + DIRTY_MEMORY_BLOCK_SIZE; + unsigned long offset = BIT_WORD((rb->offset >> TARGET_PAGE_BITS) % DIRTY_MEMORY_BLOCK_SIZE); rcu_read_lock(); -- 2.19.1 ^ permalink raw reply related [flat|nested] 33+ messages in thread
* Re: [Qemu-devel] [PATCH 3/3] ram: RAMBlock->offset is always aligned to a word 2019-04-30 3:44 ` [Qemu-devel] [PATCH 3/3] ram: RAMBlock->offset is always aligned to a word Wei Yang 2019-04-30 3:44 ` Wei Yang @ 2019-07-17 9:17 ` Paolo Bonzini 2019-07-18 1:11 ` Wei Yang 1 sibling, 1 reply; 33+ messages in thread From: Paolo Bonzini @ 2019-07-17 9:17 UTC (permalink / raw) To: Wei Yang, qemu-devel; +Cc: dgilbert, quintela On 30/04/19 05:44, Wei Yang wrote: > RAMBlock->offset is calculated by find_ram_offset, which makes sure the > offset is aligned to a word. > > This patch removes the alignment check on offset and unnecessary > variable *word*. > > Signed-off-by: Wei Yang <richardw.yang@linux.intel.com> I would add an assertion instead, but overall leaving the condition there is harmless. You still need the "else" part for the case where the length is unaligned. Paolo > --- > include/exec/ram_addr.h | 15 +++++++++------ > 1 file changed, 9 insertions(+), 6 deletions(-) > > diff --git a/include/exec/ram_addr.h b/include/exec/ram_addr.h > index 3dfb2d52fb..a7c81bdb32 100644 > --- a/include/exec/ram_addr.h > +++ b/include/exec/ram_addr.h > @@ -413,18 +413,21 @@ uint64_t cpu_physical_memory_sync_dirty_bitmap(RAMBlock *rb, > uint64_t *real_dirty_pages) > { > ram_addr_t addr; > - unsigned long word = BIT_WORD(rb->offset >> TARGET_PAGE_BITS); > uint64_t num_dirty = 0; > unsigned long *dest = rb->bmap; > > - /* offset and length is aligned at the start of a word? */ > - if (((word * BITS_PER_LONG) << TARGET_PAGE_BITS) == (rb->offset) && > - !(length & ((BITS_PER_LONG << TARGET_PAGE_BITS) - 1))) { > + /* > + * Since RAMBlock->offset is guaranteed to be aligned to a word by > + * find_ram_offset(), if length is aligned at the start of a word, go the > + * fast path. > + */ > + if (!(length & ((BITS_PER_LONG << TARGET_PAGE_BITS) - 1))) { > int k; > int nr = BITS_TO_LONGS(length >> TARGET_PAGE_BITS); > unsigned long * const *src; > - unsigned long idx = (word * BITS_PER_LONG) / DIRTY_MEMORY_BLOCK_SIZE; > - unsigned long offset = BIT_WORD((word * BITS_PER_LONG) % > + unsigned long idx = (rb->offset >> TARGET_PAGE_BITS) / > + DIRTY_MEMORY_BLOCK_SIZE; > + unsigned long offset = BIT_WORD((rb->offset >> TARGET_PAGE_BITS) % > DIRTY_MEMORY_BLOCK_SIZE); > > rcu_read_lock(); > ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [Qemu-devel] [PATCH 3/3] ram: RAMBlock->offset is always aligned to a word 2019-07-17 9:17 ` Paolo Bonzini @ 2019-07-18 1:11 ` Wei Yang 0 siblings, 0 replies; 33+ messages in thread From: Wei Yang @ 2019-07-18 1:11 UTC (permalink / raw) To: Paolo Bonzini; +Cc: quintela, Wei Yang, dgilbert, qemu-devel On Wed, Jul 17, 2019 at 11:17:50AM +0200, Paolo Bonzini wrote: >On 30/04/19 05:44, Wei Yang wrote: >> RAMBlock->offset is calculated by find_ram_offset, which makes sure the >> offset is aligned to a word. >> >> This patch removes the alignment check on offset and unnecessary >> variable *word*. >> >> Signed-off-by: Wei Yang <richardw.yang@linux.intel.com> > >I would add an assertion instead, but overall leaving the condition >there is harmless. You still need the "else" part for the case where >the length is unaligned. > Thanks, then I would leave current code untouched. >Paolo > -- Wei Yang Help you, Help me ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [Qemu-devel] [PATCH 0/3] Cleanup migration/ram.c 2019-04-30 3:44 [Qemu-devel] [PATCH 0/3] Cleanup migration/ram.c Wei Yang ` (3 preceding siblings ...) 2019-04-30 3:44 ` [Qemu-devel] [PATCH 3/3] ram: RAMBlock->offset is always aligned to a word Wei Yang @ 2019-05-01 22:53 ` no-reply 2019-05-01 22:53 ` no-reply 2019-05-02 0:10 ` Wei Yang 2019-05-02 4:24 ` no-reply 5 siblings, 2 replies; 33+ messages in thread From: no-reply @ 2019-05-01 22:53 UTC (permalink / raw) To: richardw.yang; +Cc: fam, qemu-devel, pbonzini, dgilbert, quintela Patchew URL: https://patchew.org/QEMU/20190430034412.12935-1-richardw.yang@linux.intel.com/ Hi, This series failed the docker-mingw@fedora build test. Please find the testing commands and their output below. If you have Docker installed, you can probably reproduce it locally. === TEST SCRIPT BEGIN === #!/bin/bash time make docker-test-mingw@fedora SHOW_ENV=1 J=14 NETWORK=1 === TEST SCRIPT END === The full log is available at http://patchew.org/logs/20190430034412.12935-1-richardw.yang@linux.intel.com/testing.docker-mingw@fedora/?type=message. --- Email generated automatically by Patchew [https://patchew.org/]. Please send your feedback to patchew-devel@redhat.com ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [Qemu-devel] [PATCH 0/3] Cleanup migration/ram.c 2019-05-01 22:53 ` [Qemu-devel] [PATCH 0/3] Cleanup migration/ram.c no-reply @ 2019-05-01 22:53 ` no-reply 2019-05-02 0:10 ` Wei Yang 1 sibling, 0 replies; 33+ messages in thread From: no-reply @ 2019-05-01 22:53 UTC (permalink / raw) To: richardw.yang Cc: fam, quintela, qemu-devel, dgilbert, richardw.yang, pbonzini Patchew URL: https://patchew.org/QEMU/20190430034412.12935-1-richardw.yang@linux.intel.com/ Hi, This series failed the docker-mingw@fedora build test. Please find the testing commands and their output below. If you have Docker installed, you can probably reproduce it locally. === TEST SCRIPT BEGIN === #!/bin/bash time make docker-test-mingw@fedora SHOW_ENV=1 J=14 NETWORK=1 === TEST SCRIPT END === The full log is available at http://patchew.org/logs/20190430034412.12935-1-richardw.yang@linux.intel.com/testing.docker-mingw@fedora/?type=message. --- Email generated automatically by Patchew [https://patchew.org/]. Please send your feedback to patchew-devel@redhat.com ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [Qemu-devel] [PATCH 0/3] Cleanup migration/ram.c 2019-05-01 22:53 ` [Qemu-devel] [PATCH 0/3] Cleanup migration/ram.c no-reply 2019-05-01 22:53 ` no-reply @ 2019-05-02 0:10 ` Wei Yang 2019-05-02 0:10 ` Wei Yang 1 sibling, 1 reply; 33+ messages in thread From: Wei Yang @ 2019-05-02 0:10 UTC (permalink / raw) To: qemu-devel; +Cc: richardw.yang, fam, quintela, dgilbert, pbonzini On Wed, May 01, 2019 at 03:53:01PM -0700, no-reply@patchew.org wrote: >Patchew URL: https://patchew.org/QEMU/20190430034412.12935-1-richardw.yang@linux.intel.com/ > > > >Hi, > >This series failed the docker-mingw@fedora build test. Please find the testing commands and >their output below. If you have Docker installed, you can probably reproduce it >locally. > >=== TEST SCRIPT BEGIN === >#!/bin/bash >time make docker-test-mingw@fedora SHOW_ENV=1 J=14 NETWORK=1 >=== TEST SCRIPT END === > > > > >The full log is available at >http://patchew.org/logs/20190430034412.12935-1-richardw.yang@linux.intel.com/testing.docker-mingw@fedora/?type=message. Where can I see the test case? >--- >Email generated automatically by Patchew [https://patchew.org/]. >Please send your feedback to patchew-devel@redhat.com -- Wei Yang Help you, Help me ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [Qemu-devel] [PATCH 0/3] Cleanup migration/ram.c 2019-05-02 0:10 ` Wei Yang @ 2019-05-02 0:10 ` Wei Yang 0 siblings, 0 replies; 33+ messages in thread From: Wei Yang @ 2019-05-02 0:10 UTC (permalink / raw) To: qemu-devel; +Cc: fam, pbonzini, richardw.yang, dgilbert, quintela On Wed, May 01, 2019 at 03:53:01PM -0700, no-reply@patchew.org wrote: >Patchew URL: https://patchew.org/QEMU/20190430034412.12935-1-richardw.yang@linux.intel.com/ > > > >Hi, > >This series failed the docker-mingw@fedora build test. Please find the testing commands and >their output below. If you have Docker installed, you can probably reproduce it >locally. > >=== TEST SCRIPT BEGIN === >#!/bin/bash >time make docker-test-mingw@fedora SHOW_ENV=1 J=14 NETWORK=1 >=== TEST SCRIPT END === > > > > >The full log is available at >http://patchew.org/logs/20190430034412.12935-1-richardw.yang@linux.intel.com/testing.docker-mingw@fedora/?type=message. Where can I see the test case? >--- >Email generated automatically by Patchew [https://patchew.org/]. >Please send your feedback to patchew-devel@redhat.com -- Wei Yang Help you, Help me ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [Qemu-devel] [PATCH 0/3] Cleanup migration/ram.c 2019-04-30 3:44 [Qemu-devel] [PATCH 0/3] Cleanup migration/ram.c Wei Yang ` (4 preceding siblings ...) 2019-05-01 22:53 ` [Qemu-devel] [PATCH 0/3] Cleanup migration/ram.c no-reply @ 2019-05-02 4:24 ` no-reply 2019-05-02 4:24 ` no-reply 2019-05-02 5:32 ` Wei Yang 5 siblings, 2 replies; 33+ messages in thread From: no-reply @ 2019-05-02 4:24 UTC (permalink / raw) To: richardw.yang; +Cc: fam, qemu-devel, pbonzini, dgilbert, quintela Patchew URL: https://patchew.org/QEMU/20190430034412.12935-1-richardw.yang@linux.intel.com/ Hi, This series failed the asan build test. Please find the testing commands and their output below. If you have Docker installed, you can probably reproduce it locally. === TEST SCRIPT BEGIN === #!/bin/bash time make docker-test-debug@fedora TARGET_LIST=x86_64-softmmu J=14 NETWORK=1 === TEST SCRIPT END === COPY RUNNER RUN test-debug in qemu:fedora container_linux.go:247: starting container process caused "process_linux.go:258: applying cgroup configuration for process caused \"The maximum number of active connections for UID 0 has been reached\"" /usr/bin/docker-current: Error response from daemon: oci runtime error: The maximum number of active connections for UID 0 has been reached. Traceback (most recent call last): File "./tests/docker/docker.py", line 615, in <module> sys.exit(main()) The full log is available at http://patchew.org/logs/20190430034412.12935-1-richardw.yang@linux.intel.com/testing.asan/?type=message. --- Email generated automatically by Patchew [https://patchew.org/]. Please send your feedback to patchew-devel@redhat.com ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [Qemu-devel] [PATCH 0/3] Cleanup migration/ram.c 2019-05-02 4:24 ` no-reply @ 2019-05-02 4:24 ` no-reply 2019-05-02 5:32 ` Wei Yang 1 sibling, 0 replies; 33+ messages in thread From: no-reply @ 2019-05-02 4:24 UTC (permalink / raw) To: richardw.yang Cc: fam, quintela, qemu-devel, dgilbert, richardw.yang, pbonzini Patchew URL: https://patchew.org/QEMU/20190430034412.12935-1-richardw.yang@linux.intel.com/ Hi, This series failed the asan build test. Please find the testing commands and their output below. If you have Docker installed, you can probably reproduce it locally. === TEST SCRIPT BEGIN === #!/bin/bash time make docker-test-debug@fedora TARGET_LIST=x86_64-softmmu J=14 NETWORK=1 === TEST SCRIPT END === COPY RUNNER RUN test-debug in qemu:fedora container_linux.go:247: starting container process caused "process_linux.go:258: applying cgroup configuration for process caused \"The maximum number of active connections for UID 0 has been reached\"" /usr/bin/docker-current: Error response from daemon: oci runtime error: The maximum number of active connections for UID 0 has been reached. Traceback (most recent call last): File "./tests/docker/docker.py", line 615, in <module> sys.exit(main()) The full log is available at http://patchew.org/logs/20190430034412.12935-1-richardw.yang@linux.intel.com/testing.asan/?type=message. --- Email generated automatically by Patchew [https://patchew.org/]. Please send your feedback to patchew-devel@redhat.com ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [Qemu-devel] [PATCH 0/3] Cleanup migration/ram.c 2019-05-02 4:24 ` no-reply 2019-05-02 4:24 ` no-reply @ 2019-05-02 5:32 ` Wei Yang 2019-05-02 5:32 ` Wei Yang 2019-05-02 8:35 ` Dr. David Alan Gilbert 1 sibling, 2 replies; 33+ messages in thread From: Wei Yang @ 2019-05-02 5:32 UTC (permalink / raw) To: qemu-devel; +Cc: richardw.yang, fam, quintela, dgilbert, pbonzini On Wed, May 01, 2019 at 09:24:06PM -0700, no-reply@patchew.org wrote: >Patchew URL: https://patchew.org/QEMU/20190430034412.12935-1-richardw.yang@linux.intel.com/ > > > >Hi, > >This series failed the asan build test. Please find the testing commands and >their output below. If you have Docker installed, you can probably reproduce it >locally. > >=== TEST SCRIPT BEGIN === >#!/bin/bash >time make docker-test-debug@fedora TARGET_LIST=x86_64-softmmu J=14 NETWORK=1 >=== TEST SCRIPT END === > > COPY RUNNER > RUN test-debug in qemu:fedora >container_linux.go:247: starting container process caused "process_linux.go:258: applying cgroup configuration for process caused \"The maximum number of active connections for UID 0 has been reached\"" >/usr/bin/docker-current: Error response from daemon: oci runtime error: The maximum number of active connections for UID 0 has been reached. >Traceback (most recent call last): > File "./tests/docker/docker.py", line 615, in <module> > sys.exit(main()) > May I ask how I can reproduce this? > >The full log is available at >http://patchew.org/logs/20190430034412.12935-1-richardw.yang@linux.intel.com/testing.asan/?type=message. >--- >Email generated automatically by Patchew [https://patchew.org/]. >Please send your feedback to patchew-devel@redhat.com -- Wei Yang Help you, Help me ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [Qemu-devel] [PATCH 0/3] Cleanup migration/ram.c 2019-05-02 5:32 ` Wei Yang @ 2019-05-02 5:32 ` Wei Yang 2019-05-02 8:35 ` Dr. David Alan Gilbert 1 sibling, 0 replies; 33+ messages in thread From: Wei Yang @ 2019-05-02 5:32 UTC (permalink / raw) To: qemu-devel; +Cc: fam, pbonzini, richardw.yang, dgilbert, quintela On Wed, May 01, 2019 at 09:24:06PM -0700, no-reply@patchew.org wrote: >Patchew URL: https://patchew.org/QEMU/20190430034412.12935-1-richardw.yang@linux.intel.com/ > > > >Hi, > >This series failed the asan build test. Please find the testing commands and >their output below. If you have Docker installed, you can probably reproduce it >locally. > >=== TEST SCRIPT BEGIN === >#!/bin/bash >time make docker-test-debug@fedora TARGET_LIST=x86_64-softmmu J=14 NETWORK=1 >=== TEST SCRIPT END === > > COPY RUNNER > RUN test-debug in qemu:fedora >container_linux.go:247: starting container process caused "process_linux.go:258: applying cgroup configuration for process caused \"The maximum number of active connections for UID 0 has been reached\"" >/usr/bin/docker-current: Error response from daemon: oci runtime error: The maximum number of active connections for UID 0 has been reached. >Traceback (most recent call last): > File "./tests/docker/docker.py", line 615, in <module> > sys.exit(main()) > May I ask how I can reproduce this? > >The full log is available at >http://patchew.org/logs/20190430034412.12935-1-richardw.yang@linux.intel.com/testing.asan/?type=message. >--- >Email generated automatically by Patchew [https://patchew.org/]. >Please send your feedback to patchew-devel@redhat.com -- Wei Yang Help you, Help me ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [Qemu-devel] [PATCH 0/3] Cleanup migration/ram.c 2019-05-02 5:32 ` Wei Yang 2019-05-02 5:32 ` Wei Yang @ 2019-05-02 8:35 ` Dr. David Alan Gilbert 2019-05-02 8:35 ` Dr. David Alan Gilbert 2019-05-02 22:34 ` Wei Yang 1 sibling, 2 replies; 33+ messages in thread From: Dr. David Alan Gilbert @ 2019-05-02 8:35 UTC (permalink / raw) To: Wei Yang; +Cc: qemu-devel, richardw.yang, fam, quintela, pbonzini * Wei Yang (richard.weiyang@gmail.com) wrote: > On Wed, May 01, 2019 at 09:24:06PM -0700, no-reply@patchew.org wrote: > >Patchew URL: https://patchew.org/QEMU/20190430034412.12935-1-richardw.yang@linux.intel.com/ > > > > > > > >Hi, > > > >This series failed the asan build test. Please find the testing commands and > >their output below. If you have Docker installed, you can probably reproduce it > >locally. > > > >=== TEST SCRIPT BEGIN === > >#!/bin/bash > >time make docker-test-debug@fedora TARGET_LIST=x86_64-softmmu J=14 NETWORK=1 > >=== TEST SCRIPT END === > > > > COPY RUNNER > > RUN test-debug in qemu:fedora > >container_linux.go:247: starting container process caused "process_linux.go:258: applying cgroup configuration for process caused \"The maximum number of active connections for UID 0 has been reached\"" > >/usr/bin/docker-current: Error response from daemon: oci runtime error: The maximum number of active connections for UID 0 has been reached. > >Traceback (most recent call last): > > File "./tests/docker/docker.py", line 615, in <module> > > sys.exit(main()) > > > > May I ask how I can reproduce this? To me this just looks like patchew having a problem, I don't think it's a real qemu bug. Dave > > > >The full log is available at > >http://patchew.org/logs/20190430034412.12935-1-richardw.yang@linux.intel.com/testing.asan/?type=message. > >--- > >Email generated automatically by Patchew [https://patchew.org/]. > >Please send your feedback to patchew-devel@redhat.com > > -- > Wei Yang > Help you, Help me -- Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [Qemu-devel] [PATCH 0/3] Cleanup migration/ram.c 2019-05-02 8:35 ` Dr. David Alan Gilbert @ 2019-05-02 8:35 ` Dr. David Alan Gilbert 2019-05-02 22:34 ` Wei Yang 1 sibling, 0 replies; 33+ messages in thread From: Dr. David Alan Gilbert @ 2019-05-02 8:35 UTC (permalink / raw) To: Wei Yang; +Cc: fam, pbonzini, quintela, qemu-devel, richardw.yang * Wei Yang (richard.weiyang@gmail.com) wrote: > On Wed, May 01, 2019 at 09:24:06PM -0700, no-reply@patchew.org wrote: > >Patchew URL: https://patchew.org/QEMU/20190430034412.12935-1-richardw.yang@linux.intel.com/ > > > > > > > >Hi, > > > >This series failed the asan build test. Please find the testing commands and > >their output below. If you have Docker installed, you can probably reproduce it > >locally. > > > >=== TEST SCRIPT BEGIN === > >#!/bin/bash > >time make docker-test-debug@fedora TARGET_LIST=x86_64-softmmu J=14 NETWORK=1 > >=== TEST SCRIPT END === > > > > COPY RUNNER > > RUN test-debug in qemu:fedora > >container_linux.go:247: starting container process caused "process_linux.go:258: applying cgroup configuration for process caused \"The maximum number of active connections for UID 0 has been reached\"" > >/usr/bin/docker-current: Error response from daemon: oci runtime error: The maximum number of active connections for UID 0 has been reached. > >Traceback (most recent call last): > > File "./tests/docker/docker.py", line 615, in <module> > > sys.exit(main()) > > > > May I ask how I can reproduce this? To me this just looks like patchew having a problem, I don't think it's a real qemu bug. Dave > > > >The full log is available at > >http://patchew.org/logs/20190430034412.12935-1-richardw.yang@linux.intel.com/testing.asan/?type=message. > >--- > >Email generated automatically by Patchew [https://patchew.org/]. > >Please send your feedback to patchew-devel@redhat.com > > -- > Wei Yang > Help you, Help me -- Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [Qemu-devel] [PATCH 0/3] Cleanup migration/ram.c 2019-05-02 8:35 ` Dr. David Alan Gilbert 2019-05-02 8:35 ` Dr. David Alan Gilbert @ 2019-05-02 22:34 ` Wei Yang 2019-05-02 22:34 ` Wei Yang 1 sibling, 1 reply; 33+ messages in thread From: Wei Yang @ 2019-05-02 22:34 UTC (permalink / raw) To: Dr. David Alan Gilbert Cc: Wei Yang, qemu-devel, richardw.yang, fam, quintela, pbonzini On Thu, May 02, 2019 at 09:35:50AM +0100, Dr. David Alan Gilbert wrote: >* Wei Yang (richard.weiyang@gmail.com) wrote: >> On Wed, May 01, 2019 at 09:24:06PM -0700, no-reply@patchew.org wrote: >> >Patchew URL: https://patchew.org/QEMU/20190430034412.12935-1-richardw.yang@linux.intel.com/ >> > >> > >> > >> >Hi, >> > >> >This series failed the asan build test. Please find the testing commands and >> >their output below. If you have Docker installed, you can probably reproduce it >> >locally. >> > >> >=== TEST SCRIPT BEGIN === >> >#!/bin/bash >> >time make docker-test-debug@fedora TARGET_LIST=x86_64-softmmu J=14 NETWORK=1 >> >=== TEST SCRIPT END === >> > >> > COPY RUNNER >> > RUN test-debug in qemu:fedora >> >container_linux.go:247: starting container process caused "process_linux.go:258: applying cgroup configuration for process caused \"The maximum number of active connections for UID 0 has been reached\"" >> >/usr/bin/docker-current: Error response from daemon: oci runtime error: The maximum number of active connections for UID 0 has been reached. >> >Traceback (most recent call last): >> > File "./tests/docker/docker.py", line 615, in <module> >> > sys.exit(main()) >> > >> >> May I ask how I can reproduce this? > >To me this just looks like patchew having a problem, I don't think it's >a real qemu bug. Ah, thanks. > >Dave > >> > >> >The full log is available at >> >http://patchew.org/logs/20190430034412.12935-1-richardw.yang@linux.intel.com/testing.asan/?type=message. >> >--- >> >Email generated automatically by Patchew [https://patchew.org/]. >> >Please send your feedback to patchew-devel@redhat.com >> >> -- >> Wei Yang >> Help you, Help me >-- >Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK -- Wei Yang Help you, Help me ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [Qemu-devel] [PATCH 0/3] Cleanup migration/ram.c 2019-05-02 22:34 ` Wei Yang @ 2019-05-02 22:34 ` Wei Yang 0 siblings, 0 replies; 33+ messages in thread From: Wei Yang @ 2019-05-02 22:34 UTC (permalink / raw) To: Dr. David Alan Gilbert Cc: fam, quintela, qemu-devel, Wei Yang, richardw.yang, pbonzini On Thu, May 02, 2019 at 09:35:50AM +0100, Dr. David Alan Gilbert wrote: >* Wei Yang (richard.weiyang@gmail.com) wrote: >> On Wed, May 01, 2019 at 09:24:06PM -0700, no-reply@patchew.org wrote: >> >Patchew URL: https://patchew.org/QEMU/20190430034412.12935-1-richardw.yang@linux.intel.com/ >> > >> > >> > >> >Hi, >> > >> >This series failed the asan build test. Please find the testing commands and >> >their output below. If you have Docker installed, you can probably reproduce it >> >locally. >> > >> >=== TEST SCRIPT BEGIN === >> >#!/bin/bash >> >time make docker-test-debug@fedora TARGET_LIST=x86_64-softmmu J=14 NETWORK=1 >> >=== TEST SCRIPT END === >> > >> > COPY RUNNER >> > RUN test-debug in qemu:fedora >> >container_linux.go:247: starting container process caused "process_linux.go:258: applying cgroup configuration for process caused \"The maximum number of active connections for UID 0 has been reached\"" >> >/usr/bin/docker-current: Error response from daemon: oci runtime error: The maximum number of active connections for UID 0 has been reached. >> >Traceback (most recent call last): >> > File "./tests/docker/docker.py", line 615, in <module> >> > sys.exit(main()) >> > >> >> May I ask how I can reproduce this? > >To me this just looks like patchew having a problem, I don't think it's >a real qemu bug. Ah, thanks. > >Dave > >> > >> >The full log is available at >> >http://patchew.org/logs/20190430034412.12935-1-richardw.yang@linux.intel.com/testing.asan/?type=message. >> >--- >> >Email generated automatically by Patchew [https://patchew.org/]. >> >Please send your feedback to patchew-devel@redhat.com >> >> -- >> Wei Yang >> Help you, Help me >-- >Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK -- Wei Yang Help you, Help me ^ permalink raw reply [flat|nested] 33+ messages in thread
end of thread, other threads:[~2019-07-18 1:12 UTC | newest] Thread overview: 33+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2019-04-30 3:44 [Qemu-devel] [PATCH 0/3] Cleanup migration/ram.c Wei Yang 2019-04-30 3:44 ` Wei Yang 2019-04-30 3:44 ` [Qemu-devel] [PATCH 1/3] migration/ram.c: start of migration_bitmap_sync_range is always 0 Wei Yang 2019-04-30 3:44 ` Wei Yang 2019-05-14 14:15 ` Dr. David Alan Gilbert 2019-05-14 14:27 ` Dr. David Alan Gilbert 2019-05-15 6:41 ` Wei Yang 2019-05-15 8:04 ` Dr. David Alan Gilbert 2019-05-15 8:54 ` Wei Yang 2019-04-30 3:44 ` [Qemu-devel] [PATCH 2/3] migration/ram.c: start of cpu_physical_memory_sync_dirty_bitmap " Wei Yang 2019-04-30 3:44 ` Wei Yang 2019-05-14 14:21 ` Dr. David Alan Gilbert 2019-05-31 0:54 ` Wei Yang 2019-06-21 7:43 ` Wei Yang 2019-07-17 1:13 ` Wei Yang 2019-07-17 9:16 ` Paolo Bonzini 2019-07-18 1:07 ` Wei Yang 2019-04-30 3:44 ` [Qemu-devel] [PATCH 3/3] ram: RAMBlock->offset is always aligned to a word Wei Yang 2019-04-30 3:44 ` Wei Yang 2019-07-17 9:17 ` Paolo Bonzini 2019-07-18 1:11 ` Wei Yang 2019-05-01 22:53 ` [Qemu-devel] [PATCH 0/3] Cleanup migration/ram.c no-reply 2019-05-01 22:53 ` no-reply 2019-05-02 0:10 ` Wei Yang 2019-05-02 0:10 ` Wei Yang 2019-05-02 4:24 ` no-reply 2019-05-02 4:24 ` no-reply 2019-05-02 5:32 ` Wei Yang 2019-05-02 5:32 ` Wei Yang 2019-05-02 8:35 ` Dr. David Alan Gilbert 2019-05-02 8:35 ` Dr. David Alan Gilbert 2019-05-02 22:34 ` Wei Yang 2019-05-02 22:34 ` Wei Yang
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).