[Top][All Lists]

[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: Gecko/20080226 SUSE/ Thunderbird/ Mnenhy/

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.


Siemens AG, Corporate Technology, CT RTC ITP SDP-DE
Corporate Competence Center Embedded Linux

reply via email to

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