From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:50264) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VBPhx-0006VJ-FG for qemu-devel@nongnu.org; Mon, 19 Aug 2013 09:41:28 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VBPhp-0003V4-93 for qemu-devel@nongnu.org; Mon, 19 Aug 2013 09:41:21 -0400 Received: from david.siemens.de ([192.35.17.14]:16678) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VBPho-0003Tw-Vi for qemu-devel@nongnu.org; Mon, 19 Aug 2013 09:41:13 -0400 Message-ID: <5212206B.3040507@siemens.com> Date: Mon, 19 Aug 2013 15:40:59 +0200 From: Jan Kiszka MIME-Version: 1.0 References: <5209E6A1.6060308@siemens.com> <520A467E.6000406@redhat.com> <520A4897.3090407@siemens.com> <52121BCA.6090804@redhat.com> In-Reply-To: <52121BCA.6090804@redhat.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] Using aio_poll for timer carrier threads List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Paolo Bonzini Cc: Kevin Wolf , Anthony Liguori , Stefan Hajnoczi , qemu-devel , liu ping fan , Alex Bligh , MORITA Kazutaka , Richard Henderson On 2013-08-19 15:21, Paolo Bonzini wrote: > Il 13/08/2013 16:54, Jan Kiszka ha scritto: >>>> Using an AioContext lock for timers is somewhat complicated for lock >>>> ordering, because context A could try to modify a timer from context B, >>>> at the same time when context B is modifying a timer from context A. >>>> This would cause a deadlock. >> That's like MMIO access on device A triggers MMIO access on B and vice >> versa - why should we need this, so why should we support this? I think >> the typical case is that timers (and their lists) and data structures >> they access have a fairly close relation, thus can reuse the same lock. > > Yes, that's true. Still it would have to be documented, and using > too-coarse locks risks having many BQLs, which multiplies the complexity > (fine-grained locking at least keeps critical sections small and limits > the amount of nested locking). As this lock does not require taking other locks while holding it, it should actually be fine. > > I like Stefan's patches to make the timer list thread-safe, especially > if we can optimize it (with RCU?) to make the read side lockless. What is a pure read-side in that context? Checks if some timer is expired? Given that RCU write sides are heavier than plain mutexes and many typical accesses (mod, del, expire) involve writing, such an optimization may also be counterproductive. Jan -- Siemens AG, Corporate Technology, CT RTC ITP SES-DE Corporate Competence Center Embedded Linux