Avi Kivity wrote:
Paul Brook wrote:
Yes, good thinking, but this should only be done if it actually impacts
something. Reducing overhead from 0.1% to 0.05% is not worthwhile
if it
introduces extra complexity.
If the overhead is that small, why are we touching this code in the
On Mon, 20 Aug 2007, Luca Tettamanti wrote:
Il Sun, Aug 19, 2007 at 10:31:26PM +0300, Avi Kivity ha scritto:
Luca wrote:
On 8/19/07, Luca Tettamanti [EMAIL PROTECTED] wrote:
+static uint64_t qemu_next_deadline(void) {
+uint64_t nearest_delta_us = ULLONG_MAX;
+uint64_t vmdelta_us;
On 8/20/07, malc [EMAIL PROTECTED] wrote:
On Mon, 20 Aug 2007, Luca Tettamanti wrote:
Il Sun, Aug 19, 2007 at 10:31:26PM +0300, Avi Kivity ha scritto:
Luca wrote:
On 8/19/07, Luca Tettamanti [EMAIL PROTECTED] wrote:
+static uint64_t qemu_next_deadline(void) {
+uint64_t
Avi Kivity wrote:
In this case the dyn-tick minimum res will be 1msec. I believe it should
work ok since this is the case without any dyn-tick.
Actually minimum resolution depends on host HZ setting, but - yes -
essentially you have the same behaviour of the unix timer, plus the
Jamie Lokier wrote:
Avi Kivity wrote:
In this case the dyn-tick minimum res will be 1msec. I believe it should
work ok since this is the case without any dyn-tick.
Actually minimum resolution depends on host HZ setting, but - yes -
essentially you have the same
Yes, good thinking, but this should only be done if it actually impacts
something. Reducing overhead from 0.1% to 0.05% is not worthwhile if it
introduces extra complexity.
If the overhead is that small, why are we touching this code in the first
place?
Paul
Yes, good thinking, but this should only be done if it actually
impacts
something. Reducing overhead from 0.1% to 0.05% is not worthwhile
if
it
introduces extra complexity.
If the overhead is that small, why are we touching this code in the
first
place?
Accuracy is much more important
Jamie Lokier wrote:
Paul Brook wrote:
Yes, good thinking, but this should only be done if it actually impacts
something. Reducing overhead from 0.1% to 0.05% is not worthwhile if it
introduces extra complexity.
If the overhead is that small, why are we touching this code in the