[Top][All Lists]

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

[Qemu-devel] Re: [PATCH v2 0/3] really fix -icount with iothread

From: Paolo Bonzini
Subject: [Qemu-devel] Re: [PATCH v2 0/3] really fix -icount with iothread
Date: Fri, 11 Mar 2011 14:36:49 +0100
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv: Gecko/20101209 Fedora/3.1.7-0.35.b3pre.fc14 Lightning/1.0b3pre Mnenhy/0.8.3 Thunderbird/3.1.7

On 03/11/2011 01:57 PM, Edgar E. Iglesias wrote:
Hi Paulo,

I gave this patchset a run and it runs icount and iothread very
fast in all my testcases.

Thanks, that's good news.

But, it suffers from the problem that commit
tried to fix.

If the virtual CPU goes to sleep waiting for a future timer
interrupt to wake it up, qemu deadlocks.

The timer interrupt never comes because time is driven by
icount, but the vCPU doesn't run any insns.

I'm not sure what it should wait for, though. Is vm_clock supposed to be "a count of instructions, or real time if there is need for?" So, it's not clear to me what the correct behavior should be in this case. Does it make sense to wait at all?

Thinking more about it, perhaps VCPUs should never go to sleep in icount mode if there is a pending vm_clock timer; rather time should just warp to the next vm_clock event with no sleep ever taking place. (That's my reasoning for manual -icount mode, at least; I think "-icount auto" will just work thanks to the icount_rt_handler).

Bonus question: how does -icount mode makes sense at all for SMP? :)


reply via email to

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