Re: high load with usb device

[Avi Kivity <avi@redhat.com>]

  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