[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [patch v4 00/16] push mmio dispatch out of big lock
From: |
Avi Kivity |
Subject: |
Re: [Qemu-devel] [patch v4 00/16] push mmio dispatch out of big lock |
Date: |
Mon, 29 Oct 2012 17:24:28 +0200 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:16.0) Gecko/20121016 Thunderbird/16.0.1 |
On 10/25/2012 07:13 PM, Peter Maydell wrote:
> On 25 October 2012 18:07, Avi Kivity <address@hidden> wrote:
>> On 10/25/2012 04:04 PM, Peter Maydell wrote:
>>> Is there a clear up to date description somewhere of the design and
>>> locking strategy here somewhere? I'd rather not have to try to
>>> reconstitute it by reading the whole patchset...
>>
>> It was described somewhere in a document by Marcelo and myself.
>> Basically the goal is to arrive at
>>
>> address_space_write():
>> rcu_read_lock()
>> mr = lookup()
>> mr->ref()
>> rcu_read_unlock()
>>
>> mr->dispatch()
>>
>> mr->unref()
>>
>> This is the same strategy used in many places in the kernel.
>
> Yes, but this is rather short on the details
Until Jan fleshes this out:
> (eg, does every
> device have its own lock,
No, devices which are not modified will continue to use the BQL.
> what are we doing with irqs,
Eventually they will gain fine-grained threading too. Until then, they
will be protected by the big lock (and any device which calls any irq
APIs must hold it).
> how about
> dma from devices, etc etc).
DMA will be unlocked, if done to a device which has its own lock (same
as mmio).
> It's the details of the design I'd
> like to see described...
--
error compiling committee.c: too many arguments to function
- [Qemu-devel] [patch v4 15/16] e1000: introduce unmap() to fix unplug issue, (continued)