On 09/14/2010 04:53 PM, Michael Tokarev wrote:
14.09.2010 18:45, Avi Kivity пишет:
>> 17:27:23.999996 select(13, [0 5 7 9 10 12], [], [], {1, 0}) = 2 (in [5
>> 10], left {0, 999998})<0.000009>
>> 17:27:24.000199 select(13, [0 5 7 9 10 12], [], [], {1, 0}) = 1 (in
>> [12], left {0, 998775})<0.001241>
>> 17:27:24.001666 select(13, [0 5 7 9 10 12], [], [], {1, 0}) = 2 (in [5
>> 10], left {0, 999997})<0.000006>
>> 17:27:24.001768 select(13, [0 5 7 9 10 12], [], [], {1, 0}) = 1 (in
>> [12], left {0, 999932})<0.000103>
>> 17:27:24.001985 select(13, [0 5 7 9 10 12], [], [], {1, 0}) = 2 (in [5
>> 10], left {0, 999998})<0.000005>
>> 17:27:24.002061 select(13, [0 5 7 9 10 12], [], [], {1, 0}) = 1 (in
>> [12], left {0, 998407})<0.001617>
>
> That pipe is doing a lot of damage (I don't have it, and couldn't
> reproduce your results, another pointer). Do you have CONFIG_EVENTFD
> set? If not, why not?
As I mentioned in other emails in this thread:
o yes, I do have CONFIG_EVENTFD set, and it is being used
too (fd#12 in the above strace).
I thought that was the signalfd.
o 0.13.0-rc1 behaves the same way (that is, it also shows
high load when idle -- the same 18% of host CPU), but it
has no pipe on fd#5.
I think it's host_alarm_handler()'s use of qemu_notify_event(). It's
telling the main loop to rescan pending events, even though it's called
from the main loop itself. Please drop it and rerun.
It booted for me and seems to work.
Marcelo, it's safe to remove it, yes? (except for tcg or upstream
without iothread).
--
error compiling committee.c: too many arguments to function
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
