From mboxrd@z Thu Jan 1 00:00:00 1970 From: Sasha Levin Subject: Re: [PATCH 4/6] kvm tools: Add rwlock wrapper Date: Fri, 27 May 2011 23:19:38 +0300 Message-ID: <1306527578.3217.26.camel@lappy> References: <1306426743.3065.34.camel@lappy> <20110526180518.GA3572@elte.hu> <4DDE97CE.4000302@redhat.com> <1306436223.3065.36.camel@lappy> <20110526230923.GB15983@Krystal> <1306491547.3217.9.camel@lappy> <20110527103657.GA25748@elte.hu> <1306511560.3217.23.camel@lappy> <20110527171040.GC4356@elte.hu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Cc: Mathieu Desnoyers , Pekka Enberg , Avi Kivity , john@jfloren.net, kvm@vger.kernel.org, asias.hejun@gmail.com, gorcunov@gmail.com, prasadjoshi124@gmail.com, "Paul E. McKenney" To: Ingo Molnar Return-path: Received: from mail-wy0-f174.google.com ([74.125.82.174]:60364 "EHLO mail-wy0-f174.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755298Ab1E0UT6 (ORCPT ); Fri, 27 May 2011 16:19:58 -0400 Received: by wya21 with SMTP id 21so1505916wya.19 for ; Fri, 27 May 2011 13:19:57 -0700 (PDT) In-Reply-To: <20110527171040.GC4356@elte.hu> Sender: kvm-owner@vger.kernel.org List-ID: On Fri, 2011-05-27 at 19:10 +0200, Ingo Molnar wrote: > * Sasha Levin wrote: > > > On Fri, 2011-05-27 at 12:36 +0200, Ingo Molnar wrote: > > > * Sasha Levin wrote: > > > > > > > I see that in liburcu there is an implementation of a rcu linked > > > > list but no implementation of a rb-tree. > > > > > > Another approach would be, until the RCU interactions are sorted out, > > > to implement a 'big reader lock' thing that is completely lockless on > > > the read side (!). > > > > > > It works well if the write side is expensive, but very rare: which is > > > certainly the case for these ioport registration data structures used > > > in the mmio event demux fast path! > > > > > > The write_lock() side signals all worker threads to finish whatever > > > they are doing now and to wait for the write_unlock(). Then the > > > modification can be done and the worker threads can be resumed. > > > > > > This can be updated to RCU later on without much trouble. > > > > > > The advantage is that this could be implemented with the existing > > > thread-pool primitives straight away i think, we'd need five > > > primitives: > > > > > > bread_lock(); > > > bread_unlock(); > > > bwrite_lock(); > > > bwrite_lock(); > > > > > > brlock_init(); > > > > > > and a data type: > > > > > > struct brlock; > > > > > > bread_lock()/bread_unlock() is basically just a compiler barrier. > > > bwrite_lock() stops all (other) worker threads. > > > bwrite_unlock() resumes them. > > > > > > That's all - should be 50 lines of code, unless i'm missing something > > > :-) > > > > > > Thanks, > > > > > > Ingo > > > > Isn't there something similar to this in the kernel? > > Yeah, there's include/linux/lglock.h. > > > I prefer not implementing a new lock type at the moment mostly because > > we're not tackling a bug or an immediate problem, we don't really need > > locking at the moment (we add all devices at init and don't support > > hotplug yet). So I'd rather not write code just to solve it faster but > > have it thrown away later. > > We don't have to throw it away: RCU is rather complex to pull off > here, and in many cases, where writes are very rare, brlocks are the > best solution even with RCU present. So the basic plan here is to allocate a futex(?) for each VCPU thread, and have the writer thread lock all futexes when it needs to write? If we assume we only have one writer thread, it can stay pretty simple. -- Sasha.