Hi stephan, Thanks for getting back to me, as for the mlock, we have tried it here and apparently mlock cause our system to freeze for some reason, using linux tools and ram allocation we have verified no swaps are occurring. still we have delays that cause our system to lose track. my goal as I have mentioned before is to clear/blame QEMU from/of the delays.
I am continuing to learn your simple trace. I have used it and seen how it is working. the get_clock is saved as 8 octets but is converted via ./scripts/simpletrace.py to delta_ns = timestamp - self.last_timestamp which result with illogical diff (negative to very large in a split file within few seconds) it is worth mentioning I am tracing all possible events and maybe it what cause problems. Thanks again. Nir. -----Original Message----- From: Stefan Hajnoczi [mailto:stefa...@gmail.com] Sent: Monday, August 8, 2016 6:11 PM To: Nir Levy <n...@asocsnetworks.com> Cc: qemu-devel@nongnu.org; Yan Fridland <y...@asocsnetworks.com> Subject: Re: [Qemu-devel] QEMU-guestOS latencies. On Thu, Jul 28, 2016 at 09:25:41AM +0000, Nir Levy wrote: > in addition I wish to understand ram allocation and avoid host swaps. I didn't read everything but this stood out. QEMU has a -realtime mlock=on option if you wish to mlock(2) guest memory on the host. Stefan
