From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:37340) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RAmMD-00076N-G5 for qemu-devel@nongnu.org; Mon, 03 Oct 2011 13:31:16 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RAmMB-0003AN-N8 for qemu-devel@nongnu.org; Mon, 03 Oct 2011 13:31:13 -0400 Received: from e6.ny.us.ibm.com ([32.97.182.146]:50056) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RAmMB-0003A2-B1 for qemu-devel@nongnu.org; Mon, 03 Oct 2011 13:31:11 -0400 Received: from d01relay03.pok.ibm.com (d01relay03.pok.ibm.com [9.56.227.235]) by e6.ny.us.ibm.com (8.14.4/8.13.1) with ESMTP id p93H6eEq024298 for ; Mon, 3 Oct 2011 13:06:40 -0400 Received: from d01av02.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by d01relay03.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id p93HUmOO055192 for ; Mon, 3 Oct 2011 13:30:49 -0400 Received: from d01av02.pok.ibm.com (loopback [127.0.0.1]) by d01av02.pok.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id p93HUTQ5002164 for ; Mon, 3 Oct 2011 14:30:30 -0300 From: "Aneesh Kumar K.V" In-Reply-To: <4E89A789.8080302@web.de> References: <1317640994-16559-1-git-send-email-harsh@linux.vnet.ibm.com> <4E89A789.8080302@web.de> Date: Mon, 03 Oct 2011 23:00:20 +0530 Message-ID: <87boty2dar.fsf@skywalker.in.ibm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: Re: [Qemu-devel] [PATCH 0/2] Introduce QemuRWLock List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Jan Kiszka , Harsh Prateek Bora Cc: stefanha@gmail.com, qemu-devel@nongnu.org On Mon, 03 Oct 2011 14:16:09 +0200, Jan Kiszka 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. For RCU are you suggesting to work with userspace RCU implementation at http://lttng.org/urcu -aneesh