[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [PATCH v7 41/42] Disable mlock around incoming postcopy
From: |
zhanghailiang |
Subject: |
Re: [Qemu-devel] [PATCH v7 41/42] Disable mlock around incoming postcopy |
Date: |
Fri, 7 Aug 2015 11:05:30 +0800 |
User-agent: |
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.1.0 |
On 2015/8/6 22:55, Dr. David Alan Gilbert wrote:
* Juan Quintela (address@hidden) wrote:
Amit Shah <address@hidden> wrote:
On (Tue) 14 Jul 2015 [17:22:13], Juan Quintela wrote:
"Dr. David Alan Gilbert (git)" <address@hidden> wrote:
+ if (enable_mlock) {
+ if (os_mlock() < 0) {
+ error_report("mlock: %s", strerror(errno));
+ /*
+ * It doesn't feel right to fail at this point, we have a valid
+ * VM state.
+ */
realtime_init() exit in case of os_mlock() fails, so current code is:
Yea, I was wondering the same - but then I thought: would the realtime
case want a migration to happen at all?
Then disable migration with realtime looks like saner. But that
decission don't belong to this series.
I added this patch because Zhanghailiang had reported trying to use it and it
failing.
Zhanghailiang: Do you have a use case for mlock=on and migration?
Yes, we usually configure mlock=on for VM that needs high performance, and we
also support migration for these VMs.
It works well for pre-copy migration with this configuration.
IMHO, it is better to support this for post-copy migration too~
(Or maybe we could add dynamically mlock/munlock memory command for qemu,
and let management layer to decide what to do if they want to post-copy VM with
mlocking memory ?).
- we start qemu with mlock requset
- we mlock memory
- we start postcopy
- we munlock memory
- we mlock memory
I wmill really, really preffer having a check if memory is mlocked, and
it that case, just abort migration altogether. Or better still, wait to
enable mlock *until* we have finished postcopy, no?
Amit
--
Dr. David Alan Gilbert / address@hidden / Manchester, UK
.