On 07/19/2011 08:23 PM, Jan Kiszka wrote:
On 2011-07-19 19:17, Avi Kivity wrote:
> On 07/19/2011 08:14 PM, Jan Kiszka wrote:
>>
>> Another improvement - unfortunately less transparent for user space -
>> would be to overcome the single ring buffer that forces us to hold a
>> central lock in user space while processing the entries. We rather need
>> per-device rings. While waiting for coalesced VGA MMIO being processed,
>> way too many kittens are killed.
>>
>> I have this on our agenda, but I wouldn't be disappointed as well if
>> someone else is faster.
>
> The socket mmio would have accomplished this as well.
I haven't followed the outcome in all details - is that approach dead
due to its complexity?
> One thing to
> beware of is to preserve correctness:
>
> 1) write to 0xa0000 (queued)
> 2) write to 0xa0002 (queued)
> 3) remap 0xa0000 region (executed)
Obviously, there must be 3a) here: drain all affected queues.
How do you implement this 3a, if your consumers are outside the main
process? I guess you could have an additional synchonize API (for
in-kernel consumers) or RPC (for external process consumers), but then
this is no longer a simple API.
> 4) write to 0xa000 (queued)
> 5) drain queue
>
> writes 1 and 2 go to the wrong place.
>
--
error compiling committee.c: too many arguments to function
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
