On 2015/8/6 22:55, Dr. David Alan Gilbert wrote:
* Juan Quintela (quint...@redhat.com) wrote:
Amit Shah <amit.s...@redhat.com> wrote:
On (Tue) 14 Jul 2015 [17:22:13], Juan Quintela wrote:
"Dr. David Alan Gilbert (git)" <dgilb...@redhat.com> 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 / dgilb...@redhat.com / Manchester, UK
.
