qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [RFC] queue_work proposal


From: Avi Kivity
Subject: Re: [Qemu-devel] [RFC] queue_work proposal
Date: Thu, 03 Sep 2009 11:45:36 +0300
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.1) Gecko/20090814 Fedora/3.0-2.6.b3.fc11 Thunderbird/3.0b3

On 09/03/2009 03:52 AM, Glauber Costa wrote:
Hi guys

In this patch, I am attaching an early version of a new "on_vcpu" mechanism 
(after
making it generic, I saw no reason to keep its name). It allows us to guarantee
that a piece of code will be executed in a certain vcpu, indicated by a 
CPUState.

I am sorry for the big patch, I just dumped what I had so we can have early 
directions.
When it comes to submission state, I'll split it accordingly.

As we discussed these days at qemu-devel, I am using pthread_set/get_specific 
for
dealing with thread-local variables. Note that they are not used from signal 
handlers.
A first optimization would be to use TLS variables where available.

In vl.c, I am providing a version of queue_work for the IO-thread, and other 
for normal
operation. The "normal" one should fix the problems Jan is having, since it 
does nothing
more than just issuing the function we want to execute.

The io-thread version is tested with both tcg and kvm, and works (to the extent 
they were
working before, which in kvm case, is not much)

on_vcpu() and queue_work() are fundamentally different (yes, I see the wait parameter, and I think there should be two separate functions for such different behaviours).

Why do we need queue_work() in the first place?

Is there a way to limit the queue size to prevent overflow?


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





reply via email to

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