From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ingo Molnar Subject: Re: [PATCH 4/6] kvm tools: Add rwlock wrapper Date: Fri, 27 May 2011 19:10:40 +0200 Message-ID: <20110527171040.GC4356@elte.hu> 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> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii 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: Sasha Levin Return-path: Received: from mx2.mail.elte.hu ([157.181.151.9]:59568 "EHLO mx2.mail.elte.hu" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750977Ab1E0RK4 (ORCPT ); Fri, 27 May 2011 13:10:56 -0400 Content-Disposition: inline In-Reply-To: <1306511560.3217.23.camel@lappy> Sender: kvm-owner@vger.kernel.org List-ID: * 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. Thanks, Ingo