From mboxrd@z Thu Jan 1 00:00:00 1970 From: Avi Kivity Subject: Re: stopping the system clock Date: Mon, 03 Aug 2009 18:05:49 +0300 Message-ID: <4A76FCCD.3030403@redhat.com> References: <7565EB18-EA0F-4BB1-8F45-4F30BDD3614B@student.tuwien.ac.at> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: kvm@vger.kernel.org To: Roman Steiner Return-path: Received: from mx2.redhat.com ([66.187.237.31]:40294 "EHLO mx2.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932241AbZHCPAo (ORCPT ); Mon, 3 Aug 2009 11:00:44 -0400 In-Reply-To: <7565EB18-EA0F-4BB1-8F45-4F30BDD3614B@student.tuwien.ac.at> Sender: kvm-owner@vger.kernel.org List-ID: On 07/30/2009 08:02 PM, Roman Steiner wrote: > hej hej, > > i've a question about the virtual time implementation in kvm/qemu. > with the monitor commands stop / continue you can stop and start the > guest system, but the system clock is still running. > > i\ve done the following experiment: > * start the guest system > * display the system time by running 'date' in the guest system > * stop via the monitor > * way for a minute or so > * continue via the monitor > * display the system time with 'date' in the guest system > result: the system clock of the guest system was running the whole time > > for what i need it: > i'm working on a simulation of a wireless network with at least 100 > nodes (routers). each node should be represented by a kvm instance > with a minimal os and some daemons (mainyl routing deamons). because > the system gets overloaded some processes (kvm instances) are starving > and the simulation is not working any more. so i would like to stop > and start the guest system by the simulation program to keep them in > order. therefore stopping and starting must be fast and it must be a > full stop. > Essentially, the scheduler is also stopping and starting the guests. So I think that instead of writing another scheduler to pause and unpause guests, you can adjust qemu to run time in slow motion. That should reduce the interrupt rate and therefore the system load. Not sure where exactly this needs to change, probably where qemu reads the host time and sets host timers. -- error compiling committee.c: too many arguments to function