WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

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

To: Dan Magenheimer <dan.magenheimer@xxxxxxxxxx>, Jan Beulich <JBeulich@xxxxxxxxxx>
Subject: Re: [Xen-devel] [xen-unstable test] 6947: regressions - trouble: broken/fail/pass
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
Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:user-agent:date:subject:from:to:cc:message-id :thread-topic:thread-index:in-reply-to:mime-version:content-type :content-transfer-encoding; bh=B4CqD9e4bBpJfIscH7t7dQYygZdAV/NFEkzxMIx4qTo=; b=dJj5GWmndhcqIJ4xNztjSjVZhPh5V4cjjonV1Ha5GHChr2omVmewFbhAhJ6c4HJhjs KCVS1i6f2ZIBc/U6EfPja8u/Fx9xf8M+Qle144KW4aJPmeT0o6b8pDAT/jd+aARsQVhi 0mVDQjhWD44e78sMlLDHeCvBzqDLe/MN3OAlg=
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=
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <57c7db22-3761-4c60-9277-2fab94cee60a@default>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: AcwI63f4LgyWmVEbx0uoDrCOqMUDhA==
Thread-topic: [Xen-devel] [xen-unstable test] 6947: regressions - trouble: broken/fail/pass
User-agent: Microsoft-Entourage/12.29.0.110113
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
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel

<Prev in Thread] Current Thread [Next in Thread>