[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: Jan Beulich <JBeulich@xxxxxxxxxx>
  • From: Keir Fraser <keir.xen@xxxxxxxxx>
  • Date: Mon, 02 May 2011 16:45:02 +0100
  • Cc: xen-devel@xxxxxxxxxxxxxxxxxxx
  • Delivery-date: Mon, 02 May 2011 08:45:58 -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=x8F2mPXtaTO3QP+ERooroJN0wJPAdlJoupEa4ygX4sQoB0rNtbYr4FhW9tDU/cXRT4 8HQERD7iiMdzc9pNyZqDbhi8LJPHHScXIBDzE9UVqr2XiGNBhPNtSsY19X60kziM+DGK fG2Nqi1i3k3d04vAeRNgA29jl/HOFsSeXy5Bw=
  • List-id: Xen developer discussion <xen-devel.lists.xensource.com>
  • Thread-index: AcwI3+Y3Ig6ghvMHykmRdok5Gx5lWg==
  • Thread-topic: [Xen-devel] [xen-unstable test] 6947: regressions - trouble: broken/fail/pass

On 02/05/2011 15:04, "Jan Beulich" <JBeulich@xxxxxxxxxx> wrote:

>> The most straightforward way to convert to RCU with the most similar
>> synchronising semantics would be to add a 'live' boolean flag to each
>> pirq-related struct that is stored in a radix tree. Then:
>>  * insertions into radix tree would be moved before acquisition of the
>> irq_desc lock, then set 'live' under the lock
>>  * deletions would clear 'live' under the lock, then do the actual radix
>> deletion would happen after irq_desc lock release;
>>  * lookups would happen as usual under the irq_desc lock, but with an extra
>> test of the 'live' flag.
> This still leaves unclear to me how an insert hitting a not-yet-deleted
> (but no longer live) entry should behave. Simply setting 'live' again
> won't help, as that wouldn't cover a delete->insert->delete all
> happening before the first delete's grace period expires. Nor would
> this work with populating the new data (prior to setting live) when
> the old data might sill be used.

Yes, this is why in my follow-up email I explained that a secondary lock is
needed that covers both logical and physical insertion/deletion. Then the
case you describe above cannot happen. As you say, event_lock covers us.

> But wait - what you describe doesn't need RCU anymore, at least
> as long as the code paths from radix tree insert to setting 'live'
> (and similarly from clearing 'live' to doing the radix tree delete) are
> fully covered by some other lock (d->event_lock, see below). Am
> I overlooking something?

No, I think you just misunderstand RCU. What I (and now also you, a bit
independently ;-) have described is how to synchronise writers against other
writers -- e.g., someone inserting concurrently with deleting, as you
describe above. What RCU is all about is synchronising *readers* against
writers, without needing a lock. And we still need it because the radix-tree
updates will happen under d->event_lock, which the readers in IRQ context
will not be holding. The main thing that RCU generally needs is that, when a
node is deleted from a structure (radix-tree in this case) it cannot be
freed until an RCU grace period because concurrent lock-free readers may
still hold a pointer to it. There are also other details to consider but
actually the whole RCU issue appears to be handled by Linux's radix-tree
implementation -- we just need to pull an up-to-date version across into

 -- Keir

Xen-devel mailing list



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