From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from eggs.gnu.org ([2001:4830:134:3::10]:42411)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <paolo.bonzini@gmail.com>) id 1VHLqD-00053I-5p
	for qemu-devel@nongnu.org; Wed, 04 Sep 2013 18:46:33 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <paolo.bonzini@gmail.com>) id 1VHLq4-0006eR-Ot
	for qemu-devel@nongnu.org; Wed, 04 Sep 2013 18:46:25 -0400
Received: from mail-ea0-x233.google.com ([2a00:1450:4013:c01::233]:43612)
	by eggs.gnu.org with esmtp (Exim 4.71)
	(envelope-from <paolo.bonzini@gmail.com>) id 1VHLq4-0006eE-Ht
	for qemu-devel@nongnu.org; Wed, 04 Sep 2013 18:46:16 -0400
Received: by mail-ea0-f179.google.com with SMTP id b10so511780eae.10
	for <qemu-devel@nongnu.org>; Wed, 04 Sep 2013 15:46:15 -0700 (PDT)
Sender: Paolo Bonzini <paolo.bonzini@gmail.com>
Message-ID: <5227B831.7000208@redhat.com>
Date: Thu, 05 Sep 2013 00:46:09 +0200
From: Paolo Bonzini <pbonzini@redhat.com>
MIME-Version: 1.0
References: <1378323694-12042-1-git-send-email-ncmike@ncultra.org>
	<52279102.2090208@redhat.com>
	<CAGaKXu3R3C4Lw2wg356mxd5Y_bMy9y07_CbWJH-aZzexiBabgQ@mail.gmail.com>
In-Reply-To: <CAGaKXu3R3C4Lw2wg356mxd5Y_bMy9y07_CbWJH-aZzexiBabgQ@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Subject: Re: [Qemu-devel] [RFC PATCH] Convert ram_list to RCU DQ V4
List-Id: <qemu-devel.nongnu.org>
List-Unsubscribe: <https://lists.nongnu.org/mailman/options/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.nongnu.org/archive/html/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <https://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: Mike Day <ncmike@ncultra.org>
Cc: Paul Mckenney <paulmck@linux.vnet.ibm.com>, Mathew Desnoyers <mathieu.desnoyers@efficios.com>, qemu-devel@nongnu.org, Anthony Liguori <anthony@codemonkey.ws>

Il 04/09/2013 22:48, Mike Day ha scritto:
> 
> On Wed, Sep 4, 2013 at 3:58 PM, Paolo Bonzini <pbonzini@redhat.com
> <mailto:pbonzini@redhat.com>> wrote:
>>
>> > @@ -1323,23 +1325,21 @@ static RAMBlock
> *qemu_get_ram_block(ram_addr_t addr)
>> >  {
>> >      RAMBlock *block;
>> >
>> > -    /* The list is protected by the iothread lock here.  */
>> > +    /* This assumes the iothread lock is taken here too. */
>> > +
>> >      block = ram_list.mru_block;
>> >      if (block && addr - block->offset < block->length) {
>> > -        goto found;
>> > +        return block;
>> >      }
>> > -    QTAILQ_FOREACH(block, &ram_list.blocks, next) {
>> > +    QLIST_FOREACH_RCU(block, &ram_list.blocks, next) {
>> >          if (addr - block->offset < block->length) {
>> > -            goto found;
>> > +            atomic_rcu_set(&ram_list.mru_block, block);
>>
>> I think this is not needed, block was already published into the block
>> list.  What is important is to order mru_block == NULL so that it
>> happens before the node is removed.  Which we don't do, but we can fix
>> later.
> 
> I am thinking of writing some macros and possibly reorganizing the ram
> globals into a struct so that we can update it by exchanging pointers
> atomically. It seems to disjoint right and error-prone now that we are
> making it rcu-enabled.

Note that mru_block is set in hottish paths, so changes to mru_block
need not result in copying the RAM globals.  Only changes to the list
would.  But I'm not sure yet that copying the RAM globals struct is
useful.  All we need the version flag for, is to know whether a pointer
from a previous RCU read-side critical section is still valid after a
new rcu_read_lock().

Paolo