On 2011-10-03 19:30, Aneesh Kumar K.V wrote: > On Mon, 03 Oct 2011 14:16:09 +0200, Jan Kiszka <jan.kis...@web.de> 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
