[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [xen-unstable test] 6947: regressions - trouble: broken/fail/pass

  • To: Dan Magenheimer <dan.magenheimer@xxxxxxxxxx>, Jan Beulich <JBeulich@xxxxxxxxxx>
  • From: Keir Fraser <keir.xen@xxxxxxxxx>
  • Date: Mon, 02 May 2011 18:07:51 +0100
  • Cc: xen-devel@xxxxxxxxxxxxxxxxxxx
  • Delivery-date: Mon, 02 May 2011 10:08:57 -0700
  • Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=user-agent:date:subject:from:to:cc:message-id:thread-topic :thread-index:in-reply-to:mime-version:content-type :content-transfer-encoding; b=cjYwC4S/J6NMKMDBzd8pzQN2zelMwZ0UHrFprldUY2ooTb7jQ8MseUxqMzcYhxDJSh qQAk6m92eBJsioTnm6M3TVfOsgV1StVNBgdRJAZw9e+n1/jCEyNody/5BiDxDA8mOPZL VQBmzNaNHxlWENZLizePaoVpphQvBQ69JCiyw=
  • List-id: Xen developer discussion <xen-devel.lists.xensource.com>
  • Thread-index: AcwI63f4LgyWmVEbx0uoDrCOqMUDhA==
  • Thread-topic: [Xen-devel] [xen-unstable test] 6947: regressions - trouble: broken/fail/pass

On 02/05/2011 17:36, "Dan Magenheimer" <dan.magenheimer@xxxxxxxxxx> wrote:

> I won't claim to understand RCU very well either, but I
> actually explicitly chose a pre-RCU version of the Linux
> radix tree code because tmem (which was the only user of
> the radix tree code at the time IIRC) is write-often
> AND read-often and my understanding of RCU is that it
> works best for read-often-write-infrequently trees.

That is where it gives the best performance boost (because it obviates the
need for read-side locking, with its associated overheads). But there can be
other reasons for using a lock-free synchronisation strategy -- our current
motivation, sync'ing with interrupt handlers (or, similarly, signal handlers
in Unix processes), is another common one.

In terms of the cost of switching to an RCU radix-tree implementation, for
those users that don't need it (i.e., tmem, because you have full lock-based
synchronisation) it looks like node deletions unconditionally wait for an
RCU grace period before freeing the old node. If tmem is doing a reasonable
rate of deletion it might make sense for us to make that optional, selected
when the tree is first initialised. It would be easy enough to add an
'rcu_safe' flag for that purpose. There's also a rcu_head struct added to
every tree node. Not so much we can do about that. It's only 16 bytes,
hopefully not too bad an issue for tmem.

 -- Keir

Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.