qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [RFC PATCH] main-loop: Unconditionally unlock iothread


From: Peter Crosthwaite
Subject: Re: [Qemu-devel] [RFC PATCH] main-loop: Unconditionally unlock iothread
Date: Thu, 4 Apr 2013 09:58:33 +1000

Hi Paolo,

On Wed, Apr 3, 2013 at 4:35 PM, Paolo Bonzini <address@hidden> wrote:
>
>> ---
>> Is it expected that this non-blocking condition implies lockup of the
>> iothread?
>
> No.  The idea was to make the loop cheaper when you had a qemu_notify_event()
> or bottom half, basically something that causes main_loop_wait() to wake up
> immediately multiple times.  When that happens, it is cheaper to avoid
> releasing and taking the mutex.
>
> Can you check why main_loop_wait() is returning a non-zero value without
> making any progress?
>
> Paolo
>

My best theory is that stdin thinks it is progressing when it is not.

Heres some gdb to back it up. I hung the system with the 40+paste and
dumped the state of the polled fds (from os_main_loop_wait()) at that
time. 4th array element (stdin) has a revent which makes sense, as
stdin is buffering my extra chars so a poll is going to return with
that descriptor as readable. g_poll returns 1 accordingly and this is
returned, propagating back up to vl.c as a non-zero return code giving
the illusion of progress.

I think there may be a flaw in that "any of the descriptors being
pollable" is not a good definition of progress. stdin is blocked by
the fact that the device and mux cannot accept their data anymore so
even though its readable, no meaningful read will happen. That leaves
us with having to devise more elaborate code to define progress, or we
simplify by just removing this nonblocking optimisation altogether
(original patch).

Regards,
Peter

Program received signal SIGTRAP, Trace/breakpoint trap.
0x0000000000721353 in poll ()
(gdb) jhfdg;fdhg;dfgkdfg;dfjhg;dsfjhgds;fjgsd;fjhdjhdfg^C(gdb)
(gdb) bt
#0  0x0000000000721353 in poll ()
#1  0x0000000000492ec3 in os_host_main_loop_wait (timeout=0)
    at 
/home/peterc/Petalogix/Internal/plgx_src/qemu-arm-microblazeel/main-loop.c:201
#2  0x0000000000492f43 in main_loop_wait (nonblocking=1)
    at 
/home/peterc/Petalogix/Internal/plgx_src/qemu-arm-microblazeel/main-loop.c:443
#3  0x00000000005032c5 in main_loop () at
/home/peterc/Petalogix/Internal/plgx_src/qemu-arm-microblazeel/vl.c:2043
#4  0x0000000000509783 in main (argc=20, argv=0x7fffffffcd68,
envp=0x7fffffffce10)
    at /home/peterc/Petalogix/Internal/plgx_src/qemu-arm-microblazeel/vl.c:4429
(gdb) up 1
#1  0x0000000000492ec3 in os_host_main_loop_wait (timeout=0)
    at 
/home/peterc/Petalogix/Internal/plgx_src/qemu-arm-microblazeel/main-loop.c:201
201         ret = g_poll((GPollFD *)gpollfds->data, gpollfds->len, timeout);
(gdb) step
Single stepping until exit from function poll,
which has no line number information.
os_host_main_loop_wait (timeout=0) at
/home/peterc/Petalogix/Internal/plgx_src/qemu-arm-microblazeel/main-loop.c:203
203         if (timeout > 0) {
(gdb) p/x gpollfds->len
$1 = 0x6
(gdb) p/x ((GPollFD *)gpollfds->data)[0]
$2 = {fd = 0x9, events = 0x19, revents = 0x0}
(gdb) p/x ((GPollFD *)gpollfds->data)[1]
$3 = {fd = 0x5, events = 0x19, revents = 0x0}
(gdb) p/x ((GPollFD *)gpollfds->data)[2]
$4 = {fd = 0x7, events = 0x1, revents = 0x0}
(gdb) p/x ((GPollFD *)gpollfds->data)[3]
$5 = {fd = 0xa, events = 0x1, revents = 0x0}
(gdb) p/x ((GPollFD *)gpollfds->data)[4]
$6 = {fd = 0x0, events = 0x1, revents = 0x1}
(gdb) p/x ((GPollFD *)gpollfds->data)[5]
$7 = {fd = 0x6, events = 0x1, revents = 0x0}



reply via email to

[Prev in Thread] Current Thread [Next in Thread]