qemu-devel
[Top][All Lists]
Advanced

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

[Qemu-devel] Re: [PATCH 04/22] Leave inner main_loop faster on pending r


From: Avi Kivity
Subject: [Qemu-devel] Re: [PATCH 04/22] Leave inner main_loop faster on pending requests
Date: Mon, 31 Jan 2011 15:17:56 +0200
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.13) Gecko/20101209 Fedora/3.1.7-0.35.b3pre.fc14 Lightning/1.0b3pre Thunderbird/3.1.7

On 01/31/2011 01:22 PM, Jan Kiszka wrote:
On 2011-01-31 10:52, Avi Kivity wrote:
>  On 01/27/2011 03:09 PM, Jan Kiszka wrote:
>>  If there is any pending request that requires us to leave the inner loop
>>  if main_loop, makes sure we do this as soon as possible by enforcing
>>  non-blocking IO processing.
>>
>>  At this change, move variable definitions out of the inner loop to
>>  improve readability.
>>
>>  Signed-off-by: Jan Kiszka<address@hidden>
>>  ---
>>    vl.c |   11 +++++++----
>>    1 files changed, 7 insertions(+), 4 deletions(-)
>>
>>  diff --git a/vl.c b/vl.c
>>  index 5fad700..2ebc55b 100644
>>  --- a/vl.c
>>  +++ b/vl.c
>>  @@ -1384,18 +1384,21 @@ qemu_irq qemu_system_powerdown;
>>
>>    static void main_loop(void)
>>    {
>>  +    bool nonblocking = false;
>>  +#ifdef CONFIG_PROFILER
>>  +    int64_t ti;
>>  +#endif
>>        int r;
>>
>>        qemu_main_loop_start();
>>
>>        for (;;) {
>>            do {
>>  -            bool nonblocking = false;
>>  -#ifdef CONFIG_PROFILER
>>  -            int64_t ti;
>>  -#endif
>>    #ifndef CONFIG_IOTHREAD
>>                nonblocking = cpu_exec_all();
>>  +            if (!vm_can_run()) {
>>  +                nonblocking = true;
>>  +            }
>
>  Doesn't this cause vmstop to spin?  We'll never execute
>  main_loop_wait(false) if I read the code correctly?
>

The code path is not changed, we just poll instead of wait in
main_loop_wait.

Where do we wait then?

Also, I didn't get your error scenario yet. Even if we left the loop
here, what magic would main_loop_wait do to vmstop processing? The stop
request is handled outside the loop, that's why we should leave ASAP.

I'm just missing the alternate place where we sleep. If there's no such place, we spin.

--
error compiling committee.c: too many arguments to function




reply via email to

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