Re: [Qemu-devel] [PATCH 0/2] Introduce QemuRWLock

[Jan Kiszka]

On 2011-10-03 19:30, Aneesh Kumar K.V wrote:
> On Mon, 03 Oct 2011 14:16:09 +0200, Jan Kiszka <address@hidden> wrote:
> Non-text part: multipart/signed
>> On 2011-10-03 13:23, Harsh Prateek Bora wrote:
>>> SynthFS uses rwlocks, which raise the need of a generic QemuRWLock APIs.
>>> This patchset introduces the same making necessary changes to relevant code.
>>
>> Is the impact of using a plain mutex measurable with 9pfs? Usually it
>> takes very heavy write sections or highly concurrent read sections to
>> actually make a difference. Looking at the cited code, I would dare to
>> rule out the former (even more if the malloc was moved out of the
>> critical section). But I cannot assess the latter.
>>
>> If it does matter, I would vote for introducing RCU directly.
> 
> I haven't done any measurements. The lock is taken in write mode
> when creating new file system object and is taken in read mode during
> lookup(walk) and readdir. Considering we allow creation of objects only
> during init, it mostly will be taken in read mode. Currently there is no
> deletion of object. We didn't want those parallel reads to be
> mutually exclusive.

That still doesn't answer if it justifies a new locking mechanism. RW
locks are rarely useful, a nightmare for RT, and widely obsolete when
RCU is available.

> 
> For RCU are you suggesting to work with userspace RCU implementation at 
> http://lttng.org/urcu

See http://thread.gmane.org/gmane.comp.emulators.qemu/113529. That would
also help my TCG locking optimization where I had to hack away some
ram_list changes for lock-less read access
(http://thread.gmane.org/gmane.comp.emulators.qemu/1188079).

Jan

signature.asc
Description: OpenPGP digital signature