[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [PATCH 40/40] memory: add reference counting to FlatVie
From: |
Jan Kiszka |
Subject: |
Re: [Qemu-devel] [PATCH 40/40] memory: add reference counting to FlatView |
Date: |
Wed, 08 May 2013 09:57:59 +0200 |
User-agent: |
Mozilla/5.0 (X11; U; Linux i686 (x86_64); de; rv:1.8.1.12) Gecko/20080226 SUSE/2.0.0.12-1.1 Thunderbird/2.0.0.12 Mnenhy/0.7.5.666 |
On 2013-05-07 21:44, Paolo Bonzini wrote:
> Il 07/05/2013 20:00, Jan Kiszka ha scritto:
>> On 2013-05-07 16:17, Paolo Bonzini wrote:
>>> With this change, a FlatView can be used even after a concurrent
>>> update has replaced it. Because we do not have RCU, we use a
>>> mutex to protect the small critical sections that read/write the
>>> as->current_map pointer. Accesses to the FlatView can be done
>>> outside the mutex.
>>>
>>> If a MemoryRegion will be used after the FlatView is unref-ed (or after
>>> a MemoryListener callback is returned), a reference has to be added to
>>> that MemoryRegion. For example, memory_region_find adds a reference to
>>> the MemoryRegion that it returns.
>>
>> For my understanding: Every lookup, e.g. triggered by address_space_rw,
>> will briefly reference the FlatView of that address space and drop that
>> reference again after referencing the target memory region.
>>
>> Provided that is true: If we run that lookup on an address space that
>> happens to be modified in parallel, the lookup may actually cause the
>> final deref and, thus, release of the FlatView - even if the target
>> memory region was totally unrelated to the ongoing change. That could
>> make a hot-path pay the price of an action a slow path caused. Not
>> really a beautiful concept. Even if the FlatView finalization is a
>> simple free() (that is the minimum), we would pull the memory allocator
>> into code paths that might try hard to keep a safe distance for the sake
>> of predictability.
>
> All this is correct. But I hope to get RCU in 1.6, otherwise we can use
> a bottom half. In any case, this is obviously no worse than current
> code that requires the BQL (hence the lookup would serialize against the
> free).
Sure, not a regression. But I'd like to avoid that we are moving in the
potentially wrong direction /wrt final goal. And I'm very interested in
having increments that can be used in RT demonstration scenarios without
having to hack too much on the code.
Jan
--
Siemens AG, Corporate Technology, CT RTC ITP SDP-DE
Corporate Competence Center Embedded Linux
- Re: [Qemu-devel] [PATCH 02/40] memory: allow memory_region_find() to run on non-root memory regions, (continued)
- [Qemu-devel] [PATCH 18/40] spapr: use memory core for iommu support, Paolo Bonzini, 2013/05/07
- [Qemu-devel] [PATCH 24/40] memory: add getter/setter for owner, Paolo Bonzini, 2013/05/07
- [Qemu-devel] [PATCH 07/40] memory: fix address space initialization/destruction, Paolo Bonzini, 2013/05/07
- [Qemu-devel] [PATCH 17/40] spapr: make IOMMU translation go through IOMMUTLBEntry, Paolo Bonzini, 2013/05/07
- [Qemu-devel] [PATCH 40/40] memory: add reference counting to FlatView, Paolo Bonzini, 2013/05/07
[Qemu-devel] [PATCH 09/40] memory: create FlatView for new address spaces, Paolo Bonzini, 2013/05/07
[Qemu-devel] [PATCH 38/40] memory: access FlatView from a local variable, Paolo Bonzini, 2013/05/07
[Qemu-devel] [PATCH 37/40] memory: ref/unref memory across address_space_map/unmap, Paolo Bonzini, 2013/05/07
[Qemu-devel] [PATCH 33/40] pci-assign: add memory_region_set_owner calls, Paolo Bonzini, 2013/05/07
[Qemu-devel] [PATCH 31/40] isa/portio: allow setting an owner, Paolo Bonzini, 2013/05/07
[Qemu-devel] [PATCH 36/40] memory: return MemoryRegion from qemu_ram_addr_from_host, Paolo Bonzini, 2013/05/07
[Qemu-devel] [PATCH 35/40] exec: check MRU in qemu_ram_addr_from_host, Paolo Bonzini, 2013/05/07
[Qemu-devel] [PATCH 34/40] vfio: add memory_region_set_owner calls, Paolo Bonzini, 2013/05/07