[Top][All Lists]
[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 14:32:45 +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 02:15 PM, Glauber Costa wrote:
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).
Therefore, the name change. The exact on_vcpu behaviour, however, can be
implemented ontop of queue_work().
Will there be any use for asynchronous queue_work()?
It's a dangerous API.
Instead of doing that, I opted for using it
implicitly inside kvm_vcpu_ioctl, to guarantee that vcpu ioctls will always run
on the right thread context.
I think it's reasonable to demand that whoever calls kvm_vcpu_ioctl()
know what they are doing (and they'll get surprising results if it
switches threads implicitly).
Looking at qemu-kvm, it seems that there are a couple
of other functions that are not ioctls, and need on_vcpu semantics. Using them
becomes
a simple matter of doing:
queue_work(env, func, data, 1);
I really don't see the big difference you point. They are both there to force a
specific
function to be executed in the right thread context.
One of them is synchronous, meaning the data can live on stack and no
special synchronization is needed, while the other is synchronous,
meaning explicit memory management and end-of-work synchronization is
needed.
Why do we need queue_work() in the first place?
To force a function to be executed in the correct thread context.
Why do we need on_vcpu in the first place?
on_vcpu() is a subset of queue_work(). I meant, why to we need the
extra functionality?
Is there a way to limit the queue size to prevent overflow?
It can be, but it gets awkward. What do you do when you want a function needs
to execute
on another thread, but you can't? Block it? Refuse?
What if the thread is busy? You grow the queue to an unbounded size?
We could pick one, but I see no need. The vast majority of work will never get
queued,
since we'll be in the right context already.
A more powerful API comes with increased responsibilities.
--
error compiling committee.c: too many arguments to function