From 154cc9ea3bc840199714ee7b95277c572c5d1533 Mon Sep 17 00:00:00 2001 From: "Dr. David Alan Gilbert" Date: Fri, 5 Jan 2018 17:01:37 +0000 Subject: find_ram_offset: Add comments and tracing Add some comments so I can understand the various nested loops. Add some tracing so I can see what they're doing. Signed-off-by: Dr. David Alan Gilbert Message-Id: <20180105170138.23357-2-dgilbert@redhat.com> Signed-off-by: Paolo Bonzini --- exec.c | 29 ++++++++++++++++++++++------- 1 file changed, 22 insertions(+), 7 deletions(-) (limited to 'exec.c') diff --git a/exec.c b/exec.c index 4722e52..5e2fb55 100644 --- a/exec.c +++ b/exec.c @@ -1660,7 +1660,10 @@ static void *file_ram_alloc(RAMBlock *block, } #endif -/* Called with the ramlist lock held. */ +/* Allocate space within the ram_addr_t space that governs the + * dirty bitmaps. + * Called with the ramlist lock held. + */ static ram_addr_t find_ram_offset(ram_addr_t size) { RAMBlock *block, *next_block; @@ -1673,19 +1676,29 @@ static ram_addr_t find_ram_offset(ram_addr_t size) } RAMBLOCK_FOREACH(block) { - ram_addr_t end, next = RAM_ADDR_MAX; + ram_addr_t candidate, next = RAM_ADDR_MAX; - end = block->offset + block->max_length; + candidate = block->offset + block->max_length; + /* Search for the closest following block + * and find the gap. + */ RAMBLOCK_FOREACH(next_block) { - if (next_block->offset >= end) { + if (next_block->offset >= candidate) { next = MIN(next, next_block->offset); } } - if (next - end >= size && next - end < mingap) { - offset = end; - mingap = next - end; + + /* If it fits remember our place and remember the size + * of gap, but keep going so that we might find a smaller + * gap to fill so avoiding fragmentation. + */ + if (next - candidate >= size && next - candidate < mingap) { + offset = candidate; + mingap = next - candidate; } + + trace_find_ram_offset_loop(size, candidate, offset, next, mingap); } if (offset == RAM_ADDR_MAX) { @@ -1694,6 +1707,8 @@ static ram_addr_t find_ram_offset(ram_addr_t size) abort(); } + trace_find_ram_offset(size, offset); + return offset; } -- cgit v1.1 From 801110ab22be1ef258338345fc0b645af074d5bf Mon Sep 17 00:00:00 2001 From: "Dr. David Alan Gilbert" Date: Fri, 5 Jan 2018 17:01:38 +0000 Subject: find_ram_offset: Align ram_addr_t allocation on long boundaries The dirty bitmaps are built from 'long's and there is fast-path code for synchronising the case where the RAMBlock is aligned to the start of a long boundary. Align the allocation to this boundary to cause the fast path to be used. Offsets before change: 11398@1515169675.018566:find_ram_offset size: 0x1e0000 @ 0x8000000 11398@1515169675.020064:find_ram_offset size: 0x20000 @ 0x81e0000 11398@1515169675.020244:find_ram_offset size: 0x20000 @ 0x8200000 11398@1515169675.024343:find_ram_offset size: 0x1000000 @ 0x8220000 11398@1515169675.025154:find_ram_offset size: 0x10000 @ 0x9220000 11398@1515169675.027682:find_ram_offset size: 0x40000 @ 0x9230000 11398@1515169675.032921:find_ram_offset size: 0x200000 @ 0x9270000 11398@1515169675.033307:find_ram_offset size: 0x1000 @ 0x9470000 11398@1515169675.033601:find_ram_offset size: 0x1000 @ 0x9471000 after change: 10923@1515169108.818245:find_ram_offset size: 0x1e0000 @ 0x8000000 10923@1515169108.819410:find_ram_offset size: 0x20000 @ 0x8200000 10923@1515169108.819587:find_ram_offset size: 0x20000 @ 0x8240000 10923@1515169108.823708:find_ram_offset size: 0x1000000 @ 0x8280000 10923@1515169108.824503:find_ram_offset size: 0x10000 @ 0x9280000 10923@1515169108.827093:find_ram_offset size: 0x40000 @ 0x92c0000 10923@1515169108.833045:find_ram_offset size: 0x200000 @ 0x9300000 10923@1515169108.833504:find_ram_offset size: 0x1000 @ 0x9500000 10923@1515169108.833787:find_ram_offset size: 0x1000 @ 0x9540000 Suggested-by: Paolo Bonzini Signed-off-by: Dr. David Alan Gilbert Message-Id: <20180105170138.23357-3-dgilbert@redhat.com> Signed-off-by: Paolo Bonzini --- exec.c | 4 ++++ 1 file changed, 4 insertions(+) (limited to 'exec.c') diff --git a/exec.c b/exec.c index 5e2fb55..9f4f450 100644 --- a/exec.c +++ b/exec.c @@ -1678,7 +1678,11 @@ static ram_addr_t find_ram_offset(ram_addr_t size) RAMBLOCK_FOREACH(block) { ram_addr_t candidate, next = RAM_ADDR_MAX; + /* Align blocks to start on a 'long' in the bitmap + * which makes the bitmap sync'ing take the fast path. + */ candidate = block->offset + block->max_length; + candidate = ROUND_UP(candidate, BITS_PER_LONG << TARGET_PAGE_BITS); /* Search for the closest following block * and find the gap. -- cgit v1.1 From 15a356c49ac747a7202ed703949a178a054f2a55 Mon Sep 17 00:00:00 2001 From: Pavel Dovgalyuk Date: Wed, 10 Jan 2018 16:48:46 +0300 Subject: cpu: flush TB cache when loading VMState Flushing TB cache is required because TBs key in the cache may match different code which existed in the previous state. Signed-off-by: Pavel Dovgalyuk Signed-off-by: Maria Klimushenkova Message-Id: <20180110134846.12940.99993.stgit@pasha-VirtualBox> [Add comment suggested by Peter Maydell. - Paolo] Signed-off-by: Paolo Bonzini Signed-off-by: Pavel Dovgalyuk --- exec.c | 7 +++++++ 1 file changed, 7 insertions(+) (limited to 'exec.c') diff --git a/exec.c b/exec.c index 9f4f450..d28fc0c 100644 --- a/exec.c +++ b/exec.c @@ -623,6 +623,13 @@ static int cpu_common_post_load(void *opaque, int version_id) cpu->interrupt_request &= ~0x01; tlb_flush(cpu); + /* loadvm has just updated the content of RAM, bypassing the + * usual mechanisms that ensure we flush TBs for writes to + * memory we've translated code from. So we must flush all TBs, + * which will now be stale. + */ + tb_flush(cpu); + return 0; } -- cgit v1.1