[Qemu-devel] [PATCH] memory: reverse the priority when commit

[Qemu-devel] [PATCH] memory: reverse the priority when commit

[Liu Ping Fan]

In theroy, the high priority should commit earlier, it is the same
reason as the sequence of "Lower = earlier (during add), later (during del)"

Signed-off-by: Liu Ping Fan <pingfank@linux.vnet.ibm.com>
---
 memory.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/memory.c b/memory.c
index 75ca281..ecf1df3 100644
--- a/memory.c
+++ b/memory.c
@@ -750,7 +750,7 @@ void memory_region_transaction_commit(void)
             address_space_update_topology(as);
         }
 
-        MEMORY_LISTENER_CALL_GLOBAL(commit, Forward);
+        MEMORY_LISTENER_CALL_GLOBAL(commit, Reverse);
     }
 }
 
-- 
1.7.4.4

Re: [Qemu-devel] [PATCH] memory: reverse the priority when commit

[Peter Maydell]

On 28 March 2013 08:08, Liu Ping Fan <pingfank@linux.vnet.ibm.com> wrote:
> In theroy, the high priority should commit earlier, it is the same
> reason as the sequence of "Lower = earlier (during add), later (during del)"

Hi. Could you give a bit more detail about the reason for this
change, please? Do any of our existing commit hooks currently
care about the order in which they're called (ie is this fixing
a bug), or is there some use case that would care in future?

This change may well be right but it's not immediately obvious
that begin/commit are a paired set in the same way as (say)
add/del and log_start/log_stop, so more rationale would be
helpful.

thanks
-- PMM

Re: [Qemu-devel] [PATCH] memory: reverse the priority when commit

[liu ping fan]

On Thu, Mar 28, 2013 at 10:44 PM, Peter Maydell
<peter.maydell@linaro.org> wrote:
> On 28 March 2013 08:08, Liu Ping Fan <pingfank@linux.vnet.ibm.com> wrote:
>> In theroy, the high priority should commit earlier, it is the same
>> reason as the sequence of "Lower = earlier (during add), later (during del)"
>
> Hi. Could you give a bit more detail about the reason for this
> change, please? Do any of our existing commit hooks currently
> care about the order in which they're called (ie is this fixing
> a bug), or is there some use case that would care in future?
>
> This change may well be right but it's not immediately obvious
> that begin/commit are a paired set in the same way as (say)
> add/del and log_start/log_stop, so more rationale would be
> helpful.
>
Each componet (core, kvm,vhost) should have different priority to see
the change of the memory layout, for they are async.  But oh, here
seems that I make a mistake, the sequence of commit has already make
high priority first.

Regards,
Pingfan
> thanks
> -- PMM
>